Math.trunc仅向零截断小数部分，不四舍五入也不向下取整，负数时与Math.floor结果不同；用于金额展示合理，但库存防超卖应选Math.floor；处理浮点数前需先用Math.round或toFixed(0)规避精度误差。
Math.trunc 确实能快速去掉小数部分，但它不是万能的“取整函数”——它只做截断，不四舍五入、不向零以外的方向取整，用错场景会导致业务逻辑偏差。
为什么 Math.trunc 不等于 Math.round 或 Math.floor
它只移除小数点后所有数字，保留整数部分，对正负数都统一朝零截断。这点和 Math.floor（向下取整）不同，尤其在负数时差异明显：
Math.trunc(3.9) // → 3 Math.trunc(-3.9) // → -3 Math.floor(3.9) // → 3 Math.floor(-3.9) // → -4
- 如果你的业务是「金额计算后强制丢弃分位」（如展示整数元，不四舍五入），
Math.trunc合理 - 如果是「库存数量向下取整防超卖」，该用
Math.floor，不是Math.trunc - 若输入可能为
NaN或非数字，Math.trunc会返回NaN，需提前校验
和 parseInt 比，哪个更适合数值截断？
parseInt 看似也能“去小数”，但它是字符串解析函数，行为更隐晦：
-
parseInt(3.9)→3（看似一样） -
parseInt(-3.9)→-3（也一样） - 但
parseInt("3.9px")→3，而Math.trunc("3.9px")→NaN - 更危险的是：
parseInt("0.1")→0，但parseInt("0x10")→16（按十六进制解析）
所以纯数值处理场景，Math.trunc 更安全、意图更明确；别用 parseInt 当截断工具。
实际业务中容易被忽略的边界问题
三个高频坑点：
- 传入空字符串
""或null：结果是NaN，不是0，需Number(value) || 0防御 - 极大数值（如
1e21）可能因精度丢失导致截断失真，此时应优先考虑BigInt或字符串处理 - 在金融类计算中，直接
Math.trunc(199.99 * 100)可能得19998（而非预期19999），因为199.99 * 100实际是19998.999999999996—— 截断前务必先Math.round或用toFixed(0)补精度
真正要靠 Math.trunc 安全落地，关键不在“怎么写”，而在“它是否匹配你的业务语义”——尤其是负值处理和浮点误差这两个点，几乎每次出问题都在这儿。
