js Math.floor向下取整

2026-05-13 05:00:40 1357阅读 0评论

JS 开发避坑指南：Math.floor 真的只能“向下取整”吗？

在日常前端开发中，处理数值计算几乎是家常便饭。不管是做进度条显示、分页逻辑，还是金融金额换算，Math.floor 往往是那个最先跳出来的 API。很多新手甚至老手在碰到带小数点的数字时，习惯性敲下它，觉得这就是标准的“去尾法”。

但实际上，盲目调用这个函数，有时候会让业务逻辑在边缘情况下悄悄崩盘。

方向感决定结果

理解 Math.floor 的关键，不在于它怎么取整，而在于它取整的方向。它的官方定义是向负无穷方向舍入（Round Down）。这意味着，对于正数，它确实是去掉小数部分；但对于负数，它会把绝对值变大。

来看两个最直观的例子：

console.log(Math.floor(3.9));   // 输出 3
console.log(Math.floor(-3.1));  // 输出 -4

如果你预期的结果是去掉小数位直接保留整数部分（即 -3），那么用 Math.floor 就错了。这种差异在处理温度变化、库存扣减或者坐标轴映射时，极易引发 Bug。比如在计算股票跌幅百分比，如果是 -5.8%，你希望展示为 -5 还是 -6？不同的业务规则对应着完全不同的取整方法。

分页逻辑里的陷阱

另一个高频场景是列表分页。假设有 105 条数据，每页显示 10 条。

const totalPages = Math.floor(105 / 10); 
// 得到 10

这时候你会发现，最后一项数据在第 11 页，但你的计算只显示了 10 页。用户在第 10 页翻到底，却发现下面还有内容。这里的问题出在数学定义上：你需要的是向上取整来保证容纳所有数据，而不是向下截断。

正确的做法通常是结合业务需求判断边界。如果是计算总页数，应该用 Math.ceil；如果是计算当前页最大索引值（从 0 开始），才真正轮到 Math.floor 登场。比如第 n 页的数据范围，通常是 floor(n - 1) * pageSize 到 ceil(n * pageSize) - 1。搞混这两者，UI 渲染就会多空一行或者少一条数据。

浮点数精度带来的幻觉

JavaScript 的 Number 类型本质上是双精度浮点数，这导致我们熟悉的 0.1 + 0.2 并不等于 0.3。

当你执行 Math.floor(0.1 + 0.2) * 10 时，中间步骤的微小误差可能会影响最终结果。虽然 floor 本身不会引入新误差，但它会放大之前的精度丢失问题。

在某些严谨的金融计算场景中，直接对浮点数进行 floor 操作是不安全的。更稳妥的思路是先使用专门的大数库（如 Decimal.js）处理精度，转为字符串后再转回整数处理，或者先将数值乘以固定倍数（如 100 分），转为整数运算后再还原。不要试图通过单纯的 Math 方法去解决底层的浮点存储缺陷。

当需要截断而不是向下

回到最初关于负数的问题。如果你仅仅想切断小数部分，不关心它是正还是负（比如把时间戳转换为秒数），Math.floor 并不是最优解。

此时有两个更好的选择：

Math.trunc(number)：这是现代浏览器标准支持的方法，专门用于移除小数部分，无论正负，行为一致。
parseInt(number, 10)：虽然它是解析字符串的，但在处理数值转换时，它默认也是截断小数，且兼容性极好。不过要注意，如果传入的是非数字字符开头，它会返回 NaN，而 Math 系列通常会返回 0 或 NaN 且不会报错。