JS浮点数怎么取整？Math.floor、round与parseInt对比

在 JavaScript 中，对浮点数进行取整主要依赖 Math.floor()、Math.round() 与 parseInt()。它们的核心区别在于几何收敛方向与运算机制：Math.floor() 永远沿数轴向负无穷方向寻找最大整数；Math.round() 按照距离就近四舍五入；而 parseInt() 的底层设计是解析字符串前缀，正数处理仅是顺带符合预期，遇到极小浮点数时会因科学计数法引发隐蔽 Bug。对于纯数值丢弃小数位的场景，现代工程标准首选 ES6 的 Math.trunc()。

一、Math.floor()：严格朝负无穷方向向下取整

Math.floor(x) 是数学中标准的“下取整”函数（Floor Function），其规范定义是：返回小于或等于给定数字的最大整数。

处理正浮点数时，它的表现符合绝大多数人的日常直觉——直接抹去小数部分：

Math.floor(4.2); // 4
Math.floor(4.7); // 4
Math.floor(4.999); // 4

负数取整的认知偏差

当参数进入负数区间时，许多刚接触 JavaScript 的开发者容易产生误解，误以为 Math.floor(-4.2) 会像砍掉小数一样得到 -4。但根据“小于或等于 $x$ 的最大整数”定义：在数轴上，-5 比 -4.2 更小，而 -4 实际上比 -4.2 更大。因此：

Math.floor(-4.2); // -5
Math.floor(-4.7); // -5
Math.floor(-0.1); // -1

二、Math.round()：就近四舍五入与其临界点细节

Math.round(x) 用于寻找数轴上与该浮点数距离最近的整数。当两端距离不等时，自然向距离更近的一侧靠拢：

Math.round(4.2); // 4 （距离 4 是 0.2，距离 5 是 0.8）
Math.round(4.7); // 5 （距离 5 是 0.3，距离 4 是 0.7）

负临界半数规则（-4.5 为何等于 -4？）

当遇到 0.5 这一正好处于正中央的临界值时，JavaScript 规范做出了明确规定：统一向数轴正无穷（$+∞$）方向舍入。其内部计算标准等价于：

Math.round(x) = Math.floor(x + 0.5)

这一公式导致了在负数临界点上与生活直觉的重要差异：

• 对于正数：+4.5 + 0.5 = 5.0，向下取整为 5。
• 对于负数：-4.5 + 0.5 = -4.0，向下取整为 -4！

Math.round(4.5);  // 5
Math.round(-4.5); // -4 （注意：并非 -5）
Math.round(-4.51);// -5 （距离 -5 变成了 0.49，此时才到 -5）

三、parseInt()：字符串解析器的设计本质与致命陷阱

很多开发者习惯书写 parseInt(4.9) 来获取整数 4，甚至在一些代码规范未健全的老项目中随处可见。这种写法看似有效，却混淆了数据类型与工具职责。

ECMAScript 规范中，parseInt(string, radix) 的初衷是将包含数字的文本字符串解析为指定进制的整数，例如从 "120px" 或 "32rem" 中提取纯数字。它的执行过程包含以下关键步骤：

1. 如果第一个参数不是字符串，JavaScript 会先强制执行 ToString(value) 抽象操作将其转为字符串。
2. 解析器跳过首部空格，匹配可选的 + 或 - 符号。
3. 按从左向右的顺序逐字扫描，遇到首个在当前进制下不合法的字符时，立刻停止扫描。
4. 将前面成功扫描到的数字子串换算成整数返回。

当传入浮点数 12.84 时，转换过程为：12.84 → "12.84" → 扫描到小数点 '.' 停止 → 返回 12。这使得它在正数场景下“碰巧”起到了截断小数的效果。

const num = 0.0000005;
String(num); // "5e-7"

parseInt(num, 10); // 结果是 5！而不是 0！

四、现代标准方案：Math.trunc() 与位运算

为了弥补在纯数字取整上缺乏“朝 0 截断小数”标准工具的痛点，ECMAScript 2015 (ES6) 专门引入了 Math.trunc()。

Math.trunc(x) 是原生数字运算，直接剔除任何数字的小数部分，完全朝零归拢，既不涉及昂贵且危险的字符串转换，也无惧科学计数法：

Math.trunc(4.9);        // 4
Math.trunc(-4.9);       // -4
Math.trunc(0.0000005);  // 0 （安全准确，绝不会变成 5）

关于位运算取整（| 0 与 ~~）的利弊辨析

在性能极其敏感的场景（例如 Canvas 游戏循环、粒子动画计算）中，开发者常用位操作来实现极速截断：

let a = 4.9 | 0;   // 4
let b = ~~(-4.9);  // -4

为什么位运算能取整？在 ECMAScript 规范中，所有按位运算符（如按位或 |、双按位非 ~~）都会先执行内部抽象操作 ToInt32()，将浮点数截断并转换为 32 位有符号整数。

必须注意的边界限制：因为其被限定为 32 位整数，当数值超出 $[-2^31, 2^31-1]$（即 $-2,147,483,648 \sim 2,147,483,647$）范围时，会发生整数溢出翻转：

let big = 3000000000.5; // 超过 21 亿
Math.trunc(big); // 3000000000 （正确）
big | 0;         // -1294967296 （溢出为负数，彻底损坏）

五、综合横向对比与技术决策

六、浮点数取整常见疑问与排错检查

1. 为什么 Math.floor(0.1 + 0.2) 会受到精度问题的影响？

由于 IEEE 754 双精度浮点数的二进制表示限制，0.1 + 0.2 的实际计算结果为 0.30000000000000004。在大部分取整场景下，这种极其微小的超出并未影响到整数位（例如 Math.floor(0.30000000000000004) === 0）。但如果在乘法缩放场景中：

// 预期：1.14 * 100 = 114
let val = 1.14 * 100; // 实际是 113.99999999999999
Math.floor(val);     // 得到 113！产生偏差
Math.round(val);     // 得到 114 （修复了微小浮点抖动）

在涉及货币单位换算（如元转分）时，若使用 Math.floor，务必先通过 Math.round 或 Number.EPSILON 消除微小二进制尾数抖动，再做后续计算。

2. 现有老项目中使用 parseInt 取整的代码，是否必须替换？

建议分批次评估并重构：如果变量确定是在 $[0.00001, 10^15]$ 之间的正普通数值，其运行结果与截断一致，风险暂时可控；但如果在科学计算、汇率折算、大屏图表或可能出现极小值的核心算法中，必须尽早将其重构成 Math.trunc()，以彻底规避科学计数法引发的隐性逻辑灾难。

七、总结

掌握 JavaScript 浮点数取整，核心在于分清“数学语义”与“类型机制”：

• 需要“向下对齐与保底”时，使用 Math.floor()；
• 需要“最贴近数值的四舍五入”时，使用 Math.round()，并记住负半数向正方向靠拢的规范特性；
• 单纯为了“去掉小数部分”，坚决抛弃旧式 parseInt() 的误用习惯，全面拥抱标准的 Math.trunc()；
• 只有处理类似 "16px" 这样的外部文本输入时，才显式传入基数使用 parseInt(str, 10)。