math.abs() 无显著性能开销，其隐式转换本质是 tonumber 操作；字符串、布尔、null、undefined 及对象均按规则转数值，但结果不确定易引发逻辑错误；应优先显式校验类型而非依赖隐式转换。
Math.abs() 本身不产生“强制转换开销”这一可测量的性能成本，它执行的是 JavaScript 引擎内置的类型转换逻辑——即隐式转换（coercion），而非开发者手动写的 Number() 或 parseInt()。所谓“开销”，实际体现在转换失败时的不可预测性与运行时行为，而非 CPU 时间消耗。
哪些输入会触发隐式转换
当传入非数字类型时，Math.abs() 会按 JavaScript 的 ToNumber 抽象操作规则尝试转为数值：
-
字符串：如
"-42"→ 转成-42→ 绝对值42；但"1.2.3"或"abc"→NaN -
布尔值：
true→1，false→0 -
null →
0（注意：不是NaN） -
undefined →
NaN -
对象（含数组）：先调用
toString()或valueOf()，再转数字；例如[ -5 ]→"-5"→-5→5；而{}→"[object Object]"→NaN
真正需要警惕的不是“开销”，而是结果不确定性
隐式转换看似方便，但容易掩盖数据质量问题。比如：
- 前端表单取值常为字符串，
Math.abs(input.value)在用户输错时静默返回NaN，可能引发后续计算中断或 UI 异常 -
Math.abs(null)返回0，但业务上null往往表示“缺失”，不应等同于零值 - 数组或日期对象传入后行为依赖内部
toString()实现，不同环境或版本可能有细微差异
如何验证转换是否发生且符合预期
不依赖猜测，用两步确认：
- 先用
typeof x === 'number' && isFinite(x)判断是否为有效数字 - 再对比
Math.abs(x)和Math.abs(Number(x))是否一致；若不一致，说明原始值被隐式转换了 - 对关键字段，建议显式清洗：
const num = Number(str); if (isNaN(num)) throw new Error('Invalid number');
本质上，这不是性能问题，而是类型契约问题。写清楚“这里必须是数字”，比依赖 Math.abs 的宽容转换更可靠。
