JavaScript怎么去掉小数部分实现向零取整

一、认清“向零取整”：数轴视角与关键区别

在许多初学者的认知中，“去掉小数部分”往往会被随手写成 Math.floor()。当处理正数时，这种写法确实能掩盖问题（例如 Math.floor(4.9) === 4）；但在处理负数时，两者的逻辑产生了根本性分歧。

我们从数轴的几何方向来观察：

• 向下取整（Floor）：一律向负无穷方向（数轴左侧）靠拢。因此 Math.floor(-4.9) 的结果是 -5。
• 向上取整（Ceil）：一律向正无穷方向（数轴右侧）靠拢。因此 Math.ceil(4.9) 的结果是 5。
• 向零取整（Truncate）：向坐标原点 0 靠拢，其本质是“无条件砍掉小数点后的所有数字”。正数向左靠拢，负数向右靠拢。因此 Math.trunc(-4.9) 的结果是 -4。

可以看到，向零取整的核心数学特征是：取整后的数值绝对值永远小于或等于原数的绝对值（即 |Math.trunc(x)| <= |x|）。这在需要计算坐标偏移、对齐整数网格、分批分页索引或裁剪物理速度等场景中，是保证负坐标与正坐标对称性的关键。

二、首选方案：原生 Math.trunc() 的用法与优势

ECMAScript 2015（ES6）正式引入了 Math.trunc() 函数。这是语言层面对“向零截断小数”给出的标准答案，语义最直接，代码可读性最高。

1. 基础用法与代码示例

// 正数截断：向零靠拢（变小）
console.log(Math.trunc(4.9));    // 输出: 4
console.log(Math.trunc(4.1));    // 输出: 4

// 负数截断：向零靠拢（变大）
console.log(Math.trunc(-4.9));   // 输出: -4
console.log(Math.trunc(-4.1));   // 输出: -4

// 零与微小量
console.log(Math.trunc(0.123));  // 输出: 0
console.log(Math.trunc(-0.123)); // 输出: -0

2. 隐式类型转换与特殊值处理

Math.trunc() 在执行前会将传入的参数通过规范内部的 ToNumber() 强制转换为数值类型。如果参数无法解析为合法数值，则返回 NaN：

// 字符串数字自动转换
console.log(Math.trunc("12.34"));  // 输出: 12
console.log(Math.trunc("-9.88")); // 输出: -9

// 无法转换的文本或空值
console.log(Math.trunc("abc"));    // 输出: NaN
console.log(Math.trunc(null));     // 输出: 0 (Number(null) === 0)
console.log(Math.trunc(undefined));// 输出: NaN

// 规范保留无穷大
console.log(Math.trunc(Infinity)); // 输出: Infinity

3. 老旧环境兼容垫片（Polyfill）

如果项目需要运行在不支持 ES6 的极古老环境（例如 IE11 或老旧嵌入式 WebView），可以使用三元表达式非常轻量地实现 Polyfill：

if (!Math.trunc) {
  Math.trunc = function (v) {
    v = +v; // 显式转换为数值
    if (!isFinite(v)) return v;
    return v < 0 ? Math.ceil(v) : Math.floor(v);
  };
}

三、决策路径与替代方案

在实际项目中，面对向零取整需求，我们该如何选择最合理的技术手段？下图展示了通用的推导与选型决策链：

位运算取整机制（| 0 与 ~~）

在 JavaScript 早期或在游戏循环、Canvas 像素重绘等密集运算场景中，开发者常用位运算来快速截断小数：

const a = 5.78 | 0;   // 结果: 5
const b = -5.78 | 0;  // 结果: -5
const c = ~~5.78;     // 结果: 5
const d = ~~(-5.78);  // 结果: -5

原理：ECMAScript 规范规定，所有位运算符（如 |、~、>>）在执行操作前，必须先把操作数转换为 32 位带符号整数（ToInt32）。这一转换过程直接丢弃了浮点数的尾数部分，从而在数学上达到了向零取整的效果。

四、潜藏的陷阱：位运算与 parseInt 的边界风险

虽然位运算和 parseInt 看起来都能完成“去掉小数”，但它们潜藏着极具破坏性的边界陷阱。许多生产环境中的隐蔽 Bug 正是由此引发。

// 超过 21.4 亿的经典溢出错误示例
const bigNum = 2147483648.5;

console.log(Math.trunc(bigNum)); // 正确输出: 2147483648
console.log(bigNum | 0);          // 严重错误: -2147483648 (正数变成了负数！)
console.log(~~bigNum);            // 严重错误: -2147483648

// 吞噬特殊浮点数
console.log(Math.trunc(Infinity)); // 输出: Infinity
console.log(Infinity | 0);        // 输出: 0 (静默吞噬异常)

// 极微小数值变 1 的灾难
const small = 0.0000001; // 转换为字符串是 "1e-7"

console.log(Math.trunc(small));      // 正确输出: 0
console.log(parseInt(small, 10));    // 致命错误: 1 (解析 "1e-7" 停在 'e'，返回 1)

// 极大数值同样被截断为 1
const huge = 1e21; // 转换为字符串是 "1e+21"
console.log(parseInt(huge, 10));     // 致命错误: 1

五、各方案横向对照与实践总结

我们将 JavaScript 中几种常见的取整方案在不同输入下的实际表现汇总如下：

开发落地建议清单

1. 默认无脑选择 Math.trunc(x)：无论是前端还是 Node.js 服务端，现代 JavaScript 引擎对 Math.trunc 都有深度内联优化，既保证语义清晰，又不会受限于 32 位溢出。
2. 负数计算务必警惕 Math.floor()：如果业务逻辑要求“截断小数”、“去除小数点后数据”，遇到负数必须用 Math.trunc()，切忌用 Math.floor() 替代。
3. 位运算仅作为局部微观优化：只有在编写极端追求帧率的渲染管线、物理引擎碰撞体或音视频编解码算法，且能够从数学逻辑上完全保证数据绝对不会超出 ±21.4 亿范围时，才可使用 | 0 或 ~~。
4. 彻底弃用 parseInt 处理纯数字：将 parseInt 留给解析 "16px"、"100vh" 这类带有单位的文本，不要把它当作数学截断函数使用。