JS向下取整陷阱：负数与parseInt的行为差异

一、数轴上的分歧：向下取整与向零截断

要弄清这个陷阱，首先需要明确两个截然不同的取整定义：

• 向下取整（Floor，向负无穷逼近）：寻找小于或等于当前数值的最大整数。在数轴上，无论当前数字是正还是负，取整方向永远向左（即向负无穷 $-\infty$ 靠拢）。
• 向零截断（Truncation，抹除小数）：直接舍弃小数点后所有数字，只保留整数部分。在数轴上，其取整方向永远朝向原点 0。

当处理正数（例如 3.4）时，“向左（向负无穷）”与“向原点 0”这两个运动方向恰好完全重合，所以 Math.floor(3.4) 和 parseInt(3.4) 都会得到 3。这种表象上的巧合让很多开发者留下了“parseInt 就是取整”的错误印象。

而在负数区间（例如 -3.4），矛盾立刻爆发：向左逼近负无穷会来到更小的整数 -4，而向原点靠拢则会来到绝对值更小的 -3。二者结果相差了整整 1 个单位。

图 1：数轴视角下 Math.floor（向负无穷）与 parseInt（向零截断）的移动方向与结果对比

// 正数区间：两者恰好一致
console.log(Math.floor(4.7));  // 4 (向负无穷)
console.log(parseInt(4.7, 10)); // 4 (向零截断)

// 负数区间：出现 1 个单位的偏差
console.log(Math.floor(-4.7));  // -5 (向负无穷，数值更小)
console.log(parseInt(-4.7, 10)); // -4 (向零截断，丢弃 .7)

二、parseInt 的第二重暗坑：隐式字符串转换与科学计数法

除了负数取整方向不同之外，把 parseInt 当作数学取整函数使用还存在更为隐蔽的运行机制缺陷。

根据 ECMAScript 规范，parseInt(string, radix) 的第一步并非数值计算，而是先调用内部抽象操作 ToString() 将第一个参数强制转为字符串，随后从左往右逐个扫描字符，直到遇到第一个无法识别为合法基数数字的字符为止。

图 2：parseInt() 的内部 5 步执行流程与常见隐式类型转换暗坑

这种机制导致了两个极其致命的边界问题：

1. 极小浮点数的科学计数法陷阱

在 JavaScript 中，当浮点数小于 1e-6 时，引擎在将其转换为字符串时会自动采用指数记数法（科学计数法）。

const num = 0.0000005;

console.log(String(num));        // 输出 "5e-7"
console.log(parseInt(num, 10));  // 结果竟然是 5！

当执行 parseInt(0.0000005, 10) 时，参数先被转换为字符串 "5e-7"；parseInt 从左开始解析，读到字符 '5' 属于合法十进制数，接着读到字符 'e'（在十进制下不是合法数字），解析立即停止并返回前面的数字 5。原本无限接近 0 的数字，被取整成了 5。

2. 极大浮点数的解析截断

同样地，当数值大于或等于 1e+21 时，转为字符串也会使用科学计数法：

const big = 1000000000000000000000; // 1e+21
console.log(String(big));        // 输出 "1e+21"
console.log(parseInt(big, 10));  // 输出 1（丢弃了后面的 "e+21"）

三、方案横评：Math.floor、Math.trunc、parseInt 与位运算

在实际工程中，JavaScript 提供了多种截取或规整整数的手段。我们需要从取整方向、类型开销、数值范围等关键维度理清它们的边界差异。

图 3：JavaScript 常见取整与截断方案多维对比矩阵

1. Math.floor(x) —— 真正的纯数学向下取整

Math.floor 始终严格向负无穷方向对齐。它是纯数值运算，不需要进行字符串序列化，能够安全处理 IEEE-754 双精度浮点数的整个安全整数范围（$-2^53+1$ 至 $2^53-1$）。在涉及坐标网格对齐、负数索引计算、日历周期计算时，必须选用此方案。

2. Math.trunc(x) —— ES6 官方推荐的向零截断

如果你确实需要“直接抹去小数部分”这一行为，ES6 引入的 Math.trunc() 是唯一的标准方案。它直接对数值进行位运算级别的截断，不产生任何字符串转换开销，完全规避了 0.0000005 变成 5 的科学计数法缺陷，也不会受 32 位整型溢出的影响。

console.log(Math.trunc(4.9));   // 4
console.log(Math.trunc(-4.9));  // -4
console.log(Math.trunc(0.0000005)); // 0（正确抹除小数）

3. 按位或与双波浪号（x | 0 / ~~x）

在老旧代码或部分图形库中，常常能见到 ~~x 或 x | 0 的写法。位运算操作符会先将操作数强制转换为 32 位有符号整数（ToInt32），然后再执行计算，这一步也会顺带丢弃小数部分（向零截断）。

位运算的主要限制在于数值边界：一旦数字超过了 32 位有符号整数范围（即大于 $2^31-1 = 2,147,483,647$ 或小于 $-2^31 = -2,147,483,648$），就会发生符号翻转和数值溢出：

const large = 3000000000.5;
console.log(Math.trunc(large)); // 3000000000 (正确)
console.log(large | 0);          // -1294967296 (32位溢出变为负数！)

在现代 JavaScript 引擎中，Math.trunc() 已经被内联高度优化，位运算早已没有不可替代的性能优势，反而增加了可读性成本与溢出风险。

四、业务场景实操选型指南

根据输入数据的类型与业务逻辑的数学预期，可以参考如下决策流程挑选最稳健的解决方案：

图 4：JavaScript 整数转换与取整选型决策树

场景分类与代码范式

五、总结与编码规范自查清单

“向下取整”在数学上特指朝负无穷逼近，绝不能与“向零截断”混淆。在日常编码与代码评审（Code Review）中，建议遵循以下三条准则：

1. 禁止对非字符串使用 parseInt：如果变量本身已是 Number 类型，无论正负，都不应传入 parseInt。
2. 使用 parseInt 必须传递基数：写明 parseInt(str, 10)，杜绝无基数调用。
3. 明确负数取整语义：在编写涉及负数区间的计算逻辑时，主动向团队明确需求是“向负无穷对齐（使用 Math.floor）”还是“丢弃小数（使用 Math.trunc）”。