为什么JS中Math.floor(-3.5)结果是-4？负数取整避坑指南

一、直觉偏差：为什么初学者会误以为是 -3？

在刚开始接触编程时，大部分开发者第一次使用 Math.floor 都是在正数场景下。例如：

console.log(Math.floor(3.2));  // 输出：3
console.log(Math.floor(3.5));  // 输出：3
console.log(Math.floor(3.9));  // 输出：3

在正数环境中，Math.floor(3.5) 的输出看起来与“直接去掉小数点后的 .5”一模一样。这种巧合很容易让人在大脑中建立起错误的经验映射：以为 floor 就是“抹平零头、截断小数”。

一旦将同样的经验套用到负数上，直觉就会翻车。很多开发者在心里把 -3.5 当作“负号 + 3.5”，认为抹去 .5 应该剩下 -3。然而，在标准的 ECMAScript 规范与数学体系中，floor 对应的是高斯取整函数（Floor Function，记作 $\lfloor x floor$），其形式化定义为：

现在我们拿着这个定义来做初中数学的比较运算：

• 我们想要取整的值是：x = -3.5。
• 如果结果取 -3：由于 -3 > -3.5，-3 严格大于输入值，直接违反了“不大于（not greater than）”的数学前提！
• 如果结果取 -4：由于 -4 < -3.5，在所有小于 -3.5 的整数集合 {..., -6, -5, -4} 中，最大的整数正是 -4。

因此，Math.floor(-3.5) 返回 -4 并不是 JavaScript 的设计失误，而是严格遵循数学规律的正确表现。

图 1：数轴几何映射 —— 观察正数与负数在 Math.floor 下的向左移动路径

二、横向对比：JavaScript 五大取整方式全景剖析

在 JavaScript 中，处理浮点数转换为整数的常用方式主要有五种：Math.floor、Math.trunc、Math.ceil、Math.round 以及位运算（如 | 0 或 ~~）。掌握它们在正数与负数下的方向性差异，是避免线上 Bug 的关键。

图 2：JavaScript 常见取整方法在正负数下的表现矩阵全景

1. Math.trunc(x) —— 真正的“向零截断”

如果你在业务中寻找的正是“去掉小数部分，只要整数”，那么 ES6 引入的 Math.trunc() 才是真正符合这一直觉的工具。它的逻辑非常单纯：无论正数还是负数，直接将小数点后的尾数削掉，即向原点 0 靠近。

console.log(Math.trunc(3.5));   // 3
console.log(Math.trunc(-3.5));  // -3（向 0 截断）

2. Math.ceil(x) —— 向上取整（向正无穷靠近）

Math.ceil 与 Math.floor 刚好互为镜像。它的定义是“不小于 x 的最小整数”，在数轴上永远向右（即正无穷 $+\infty$）移动：

console.log(Math.ceil(3.1));   // 4
console.log(Math.ceil(-3.5));  // -3（因为 -3 >= -3.5，在右侧）

3. Math.round(x) —— 四舍五入与极其隐蔽的“负半数陷阱”

许多人以为 Math.round 是关于原点对称四舍五入的，即既然 round(3.5) === 4，那么 round(-3.5) 应该是 -4。然而真实执行结果却会让你大吃一惊：

console.log(Math.round(3.5));   // 4
console.log(Math.round(-3.5));  // -3！而不是 -4！
console.log(Math.round(-3.51)); // -4

4. 位运算符（x | 0、~~x、x >> 0）—— 32 位整型截断

在过往的代码库中，我们经常能看到使用双按位非 ~~x 或者按位或零 x | 0 来快速取整的技巧：

console.log(-3.5 | 0);   // -3（表现类似 trunc）
console.log(~~(-3.5));   // -3

位运算符内部首先会将浮点数按照规范的 ToInt32() 算法转为 32 位带符号整数，其过程会自动丢弃小数位，因此对于小于 $2^31-1$ 的小数，表现与 Math.trunc 一致。但是一旦超过 32 位整型边界，就会发生灾难性的数值翻转。

三、四大典型踩坑场景与实战复盘

理解了基本原理后，我们通过实际工程中四个最容易出现负数取整 Bug 的场景，看看不当使用会造成什么严重后果，以及如何编写正确的防御代码。

场景 1：2D/3D 世界网格（Tile Map）与无限画布索引计算

在游戏开发、地图渲染（如高德/Google Maps 瓦片）或无限画板中，经常需要将世界物理坐标 x 映射为离散的网格单元编号。每个网格宽度假设为 100px：

// 错误做法：使用 Math.trunc 或位运算取整
function getGridIndexWrong(x, size = 100) {
  return Math.trunc(x / size);
}

console.log(getGridIndexWrong(50));   // 0 (属于 [0, 100))
console.log(getGridIndexWrong(-50));  // 0！翻车：[-100, 0) 也被映射成了 0！

问题本质：如果使用向零截断的 Math.trunc，在 (-100, 0) 范围内的点会被算作 0，而在 (0, 100) 范围内的点也会被算作 0。这就导致第 0 号网格的物理宽度变成了 200px（其他网格都只有 100px），造成所谓的零号单元格空间塌陷！玩家在穿过坐标原点时，碰撞判定和瓦片加载会发生大面积穿模与错位。

正确解法：在连续空间划分网格时，必须且只能使用 Math.floor，因为它保证了负数区间和正数区间每一个单元格都是左闭右开且严格等宽的：

// 正确做法：空间划分必须使用 Math.floor
function getGridIndexCorrect(x, size = 100) {
  return Math.floor(x / size);
}

console.log(getGridIndexCorrect(50));   //  0 (覆盖区间 [0, 100))
console.log(getGridIndexCorrect(-50));  // -1 (覆盖区间 [-100, 0))，完美连续！

场景 2：计费抹零与负数退款差额调整

电商系统常见规则是“抹去角分”。例如实付 15.8 元，抹零后收取 15 元。很多开发人员随手写了 Math.floor(amount)。在正向支付中一切正常，但在发生售后逆向扣款、补偿金反向扣减时：

// 某账户由于违规需反向扣减余额，原始差额为 -15.2 元
const rawPenalty = -15.2;

// 错误做法：套用正向支付的 floor 逻辑
const finalPenaltyWrong = Math.floor(rawPenalty); 
// 结果变成 -16！用户原本应扣 15.2，被抹零后反而多扣除了 0.8 元，直接引发客诉！

// 正确做法：财务抹零意为“舍弃小数部分保留整数位”，应使用 Math.trunc
const finalPenaltyCorrect = Math.trunc(rawPenalty);
// 结果为 -15，符合实际业务抹除小数的要求

场景 3：大数值场景下滥用位运算引发溢出

很多人习惯写 ~~x 来偷懒替代取整，但当数值涉及 UNIX 毫秒时间戳（约 1.7 万亿）或者统计大数时，32 位整数上限 $2^31-1 = 2147483647$ 会迅速击穿代码：

const timestampMs = 1730000000500.8; // 时间戳
console.log(~~timestampMs);         // 输出：-1200590492（发生符号翻转与严重溢出！）
console.log(Math.trunc(timestampMs));// 输出：1730000000500（安全可靠）

结论：在现代 V8 等现代 JS 引擎中，Math.trunc 与 Math.floor 已经被高度内联优化，性能与位运算几乎没有实质差异。为了代码的健壮性，绝不可在业务逻辑中滥用位运算符替代取整。

场景 4：IEEE 754 浮点数微小误差导致 floor 越界

在 JavaScript 中，经过多次加减除运算后，原本应该刚好为 -3 的结果可能会因为浮点精度漂移变成 -3.0000000000000004。此时如果直接执行 Math.floor，就会触发离散跳跃：

const calculated = -1.0 - 2.0000000000000004; // 理论应为 -3
console.log(Math.floor(calculated));            // 输出：-4！（由于比 -3 小了一点点，被直接打入 -4）

四、技术选型决策树与避坑排查步骤

为了帮助大家在日常编码和 Code Review 时快速选对方法，可以按照以下决策流程逐步排查：

图 3：负数取整技术选型与排查步骤流程图

1. 第一步：明确核心意图是“空间离散连续”还是“数值大小截断”？
   • 如果是在做网格映射、区间离散化、虚拟列表滚动行计算：坚定选择 Math.floor。
   • 如果只是要把浮点数转化为整数字符串、耗时去除毫秒、计费保留整数元：坚定选择 Math.trunc。
2. 第二步：是否涉及四舍五入需求？
   • 如果要求统计学意义上的严格对称四舍五入（即 -3.5 应当进位到 -4）：绝不能直接用 Math.round，而要用下文提供的对称四舍五入工具函数。
3. 第三步：数值是否可能超过 21 亿或带有微小浮点抖动？
   • 严禁使用 | 0 或 ~~；高精度网格计算前引入 Number.EPSILON 容差缓冲。

五、生产环境防御性工具函数库

在团队协作中，为了避免不同成员对 floor、trunc 和 round 理解不一致，建议在项目的 mathUtils.ts 中沉淀以下几个具有明确业务语义的工具函数：

/**
 * 1. 严格对称四舍五入（解决 Math.round(-3.5) === -3 的正向偏置缺陷）
 *    例：symmetricRound(3.5) === 4, symmetricRound(-3.5) === -4
 */
export function symmetricRound(num) {
  const sign = Math.sign(num);
  return sign * Math.round(Math.abs(num));
}

/**
 * 2. 空间网格安全取整（引入微小 epsilon 容差，防止 -3.0000000000000004 误跳到 -4）
 */
export function safeGridFloor(num, eps = 1e-9) {
  return Math.floor(num + eps);
}

/**
 * 3. 业务抹零/截断（显式替代容易引发误解的 floor）
 */
export function truncateToZero(num) {
  return Math.trunc(num);
}

图 4：负数取整四大典型避坑卡片与修复方案总结

六、总结与核心心智模型

回到最初的问题：为什么 JS 中 Math.floor(-3.5) 的结果是 -4？

因为 Floor（地板）在数轴上永远处于“下方/左侧”。它所执行的动作是向负无穷方向靠拢，寻找所有小于等于原值的整数中离它最近的那一个。在正数世界里，向左走恰好表现为“数字变小、舍去小数”；而在负数世界里，向左走意味着绝对值变得更大，因而 -3.5 会滑向更深处的 -4。

记住一条简单的判别口诀：