Math.trunc 专为纯截断设计，不进行方向性取整，负数时与 Math.floor 不同，且比 parseInt 和位运算更安全准确：parseInt 会误解析科学计数法，位运算在 ±2³¹ 外溢出，而 Math.trunc 支持大数、保持 NaN/Infinity、语义清晰。
Math.trunc 为什么比 Math.floor 和 parseInt 更适合「纯截断」
因为 Math.trunc 不做任何方向性取整，它只砍掉小数部分，保留整数符号。负数时和 Math.floor 行为完全不同：Math.trunc(-3.7) 是 -3，而 Math.floor(-3.7) 是 -4。如果你要的是“去掉小数点后所有内容”，不是“向下取整”，Math.trunc 就是唯一语义准确的选择。
用 parseInt 模拟会出问题：它会先转字符串再解析，遇到科学计数法或前导空格可能误判，比如 parseInt(" -42.9") 得 -42 看似对，但 parseInt("1e2") 得 1（不是 100），而 Math.trunc(1e2) 正确返回 100。
哪些场景下必须用 Math.trunc 而不能用位运算替代
位运算（如 x | 0 或 ~~x）在 -2³¹ 到 2³¹−1 范围内能模拟截断，但超出该范围就会溢出或丢失精度。例如：
Math.trunc(2147483648) // 2147483648（正确） 2147483648 | 0 // -2147483648（错误！符号翻转）
所以当你的输入可能来自时间戳、大 ID、坐标值或任意用户输入时，位运算是危险的。只有明确控制输入范围且追求极致性能的底层逻辑（如 WebGL 坐标归一化）才考虑它。
- 输入可能 ≥ 2³¹ 或 ≤ −2³¹ → 必须用
Math.trunc - 需要处理
NaN、Infinity→Math.trunc返回原值（Math.trunc(NaN)是NaN），位运算会强制转为0 - 代码可读性优先 →
Math.trunc(x)比x | 0更直白表达“我要截断”
和 Number.parseInt(x, 10) 的关键区别在哪
两者行为在多数正数上一致，但有三处硬差异：
-
Number.parseInt("42.9", 10)返回42，但Number.parseInt("42.9.1", 10)也返回42（它只解析开头合法数字）；Math.trunc对非数字输入直接报错或返回NaN（如Math.trunc("42.9.1")是NaN） -
Number.parseInt会尝试类型转换，Number.parseInt(null)是NaN，但Number.parseInt(undefined)也是NaN；而Math.trunc(undefined)报TypeError（不能转换为数字） - 性能上，
Math.trunc是纯数值操作，不涉及字符串切分和进制解析，对已知数字变量更快更轻量
实际使用时容易忽略的边界情况
别假设传入一定是 number 类型——尤其从表单、URL 参数或 API 响应里拿到的值往往是 string。直接 Math.trunc("123.45") 不会报错，但结果是 123，因为 JS 会隐式转成 number；但如果字符串含非数字字符（如 "123px"），就会得 NaN。
- 安全做法：先
Number(x)再Math.trunc，而不是依赖隐式转换 -
Math.trunc(0.0000001)返回0，没问题；但Math.trunc(1e-16)在某些引擎中可能因浮点精度表现为0，这不是Math.trunc的 bug，而是输入本身已不可靠 - 注意
Math.trunc(-0)返回-0，和-0本身一样，不是0—— 如果后续要做 === 比较或 JSON 序列化，这点可能暴露
真正麻烦的从来不是函数怎么写，而是你传给它的那个值，到底是不是你以为的那个值。
