JS中parseInt与Math.floor处理负数时的区别是什么

在前端坐标计算或负向分页偏移的场景中，如果开发者将原本用于正数的取整代码直接复用到负数上，往往会触发一个相差 1 的隐蔽 Bug。例如针对 -3.7，执行 parseInt(-3.7) 得到的是 -3，而执行 Math.floor(-3.7) 得到的却是 -4。

造成这一差异的根本原因在于两者的数学定义与设计目标完全不同：parseInt 的取整行为本质是向零截断（Truncation towards zero），直接丢弃数值的小数部分；而 Math.floor 的数学定义是向下取整（Floor rounding），即取不大于当前数值的最大整数（往负无穷大 $-\infty$ 方向靠拢）。在正数范围内，向零与向负无穷方向一致，因此两者表现相同；但进入负数区间后，两种规则的方向彻底相反，结果随之分道扬镳。

一、直观对比：数轴上的两个方向

理解这个区别最直观的方式是将数值放置在数轴上观察。数轴从左向右依次增大，从 $-\infty$ 经过原点 0 延伸至 $+\infty$。

对于正数 3.7：

• parseInt(3.7)：丢弃小数 .7，朝原点 0 靠近，结果为 3。
• Math.floor(3.7)：寻找满足 $\le 3.7$ 的最大整数，朝左侧 $-\infty$ 靠近，结果同样为 3。

但是当数值变为负数 -3.7 时：

• parseInt(-3.7)：保留负号并直接剔除小数 .7，数值从 -3.7 走向 -3（向原点 0 靠拢，数值实际增大了）。
• Math.floor(-3.7)：寻找满足 $\le -3.7$ 的最大整数。因为 -3 严格大于 -3.7，所以不大于它的最大整数只能是继续向左的 -4（数值变小了）。

二、底层执行机制：字符串解析器 vs 浮点数学运算

除了取整方向上的差异，两个函数的底层实现与类型转换逻辑也存在根本性的代沟。parseInt 原生并不是为了数学取整而设计的，而是一个字符串词法解析器；Math.floor 则是专门服务于 IEEE 754 双精度浮点数的纯数学函数。

1. parseInt 的执行流水线

根据 ECMAScript 规范，parseInt(string, radix) 的第一步是强制将入参通过 ToString() 转换为字符串：

1. 如果传入数字 -3.7，JS 引擎先将其序列化为字符串 "-3.7"。
2. 词法分析器从首字符开始扫描：识别出符号位 '-'，接着识别有效十进制字符 '3'。
3. 遇到小数点 '.' 时，判定它不是十进制整数的合法字符，词法分析在此立即截断终止，后续的所有字符都被直接忽略。
4. 将已捕获的字符片段 "-3" 解析为数值 -3 返回。

2. Math.floor 的执行流水线

Math.floor(x) 是严格的数学运算符：

1. 如果入参不是数字，通过 ToNumber() 尝试转换为标准数值。
2. 在二进制浮点表示下，直接依据数学定义执行向下取整算法，返回不大于参数的最小上限整数。
3. 整个过程完全在数值与浮点位级别进行，不涉及任何字符串拼接或字符扫描。

3. 由此引发的典型陷阱

正因为 parseInt 依赖 ToString()，当处理科学计数法表示的小数时，会出现极其危险的反直觉结果。请看以下示例：

// 示例 1：常规浮点数
console.log(parseInt(-3.7));       // 输出: -3
console.log(Math.floor(-3.7));     // 输出: -4

// 示例 2：绝对值极小的负数（触发 JS 科学计数法）
const smallNegative = -0.0000008;
console.log(String(smallNegative)); // 输出: "-8e-7"
console.log(parseInt(smallNegative)); 
// 示例输出: -8  (因为解析字符串 "-8e-7" 时，遇到 'e' 停滞，提取出 -8！)

console.log(Math.floor(smallNegative));
// 示例输出: -1  (满足 <= -0.0000008 的最大整数，纯数学正确)

三、业务场景选择与决策边界

在实际工程开发中，究竟什么时候用 parseInt，什么时候用 Math.floor，以及什么时候应该使用 ES6 推荐的更佳替代品？我们可以通过具体的业务需求来判定。

场景 1：解析包含 CSS 单位或前缀的字符串

当输入源是包含非数字后缀的字符串时（如从 DOM 样式计算中读取的位移属性 "-24.5px"），必须使用 parseInt，并显式传入基数 10：

const offsetStr = "-24.5px";

// parseInt 能够正确识别前缀数字，丢弃 "px"
const parsed = parseInt(offsetStr, 10); // 结果: -24

// Math.floor 尝试将整个字符串转数值，转换失败返回 NaN
const floored = Math.floor(offsetStr);   // 结果: NaN

场景 2：网格坐标系统、平铺地图与负向分页

在图形渲染、Canvas 画布拖拽或瓦片地图中，需要将浮点坐标吸附到离散的网格单元上。若每个网格尺寸为 10px，坐标范围应连续分布：

• 区间 $[0, 10)$ 属于网格 0；
• 区间 $[-10, 0)$ 属于网格 -1；
• 区间 $[-20, -10)$ 属于网格 -2。

此时必须使用 Math.floor，因为它保证了整个数轴上每个单位区间的长度恒为 1。如果错误使用 parseInt，区间 $(-10, 10)$ 之间的所有浮点数都会被归为 0，导致原点处的网格宽度变成其他网格的两倍（严重变形）。

function getGridIndex(coord, gridSize = 10) {
  // 必须使用 Math.floor 保证正负区间连续无重叠、无膨胀
  return Math.floor(coord / gridSize);
}

console.log(getGridIndex(15));   // 输出: 1
console.log(getGridIndex(5));    // 输出: 0
console.log(getGridIndex(-5));   // 输出: -1  (正确)
console.log(getGridIndex(-15));  // 输出: -2  (正确)

场景 3：纯数值的“向零截断”（丢弃小数位）

如果你仅仅是希望对纯数值进行截断（正数截断为较小整数，负数截断为较大整数，即保留符号丢弃小数位），在现代 JavaScript 中，推荐使用 ES6 引入的 Math.trunc()，它比 parseInt 更安全、性能更高，且不会遭受科学计数法陷阱：

// 现代 JS 推荐写法
console.log(Math.trunc(-3.7)); // 输出: -3
console.log(Math.trunc(3.7));  // 输出: 3
console.log(Math.trunc(-0.0000008)); // 输出: -0 (完全符合数学预期)

四、关键维度全景对比总结

为了让不同场景下的函数特性一目了然，下表汇总了 parseInt、Math.floor 以及现代替代方案 Math.trunc 的核心指标：

五、总结

总结来说，parseInt 与 Math.floor 在处理负数时的核心区别可归纳为两句话：

• 取整方向的本质分歧：parseInt 做的是向零截断（去掉小数，数轴向右移向 0），因此 -3.7 变为 -3；而 Math.floor 做的是向下取整（数轴向左移向 $-\infty$），因此 -3.7 变为 -4。
• 适用职责的明确划分：处理带有字符单位的文本解析时选用 parseInt(str, 10)；构建连续网格与数学坐标吸附时必须使用 Math.floor(num)；而在需要纯数值丢弃小数位的现代开发中，优先使用 Math.trunc(num) 替代 parseInt。