原始类型转换开销极小，但大规模循环中频繁或隐式转换可能产生可观测影响；推荐用 performance.now 精确测量单次耗时，避免 date.now()（精度仅毫秒）。
原始类型转换本身开销极小，几乎可忽略不计，但频繁或隐式转换在大规模循环中可能被放大。测试重点不是“有没有损耗”，而是“在什么场景下会构成可观测影响”。下面提供几种实用、可复现的测试方法。
用 performance.now 精确测量单次转换耗时
这是最推荐的方式，精度达微秒级，适合对比不同转换写法的差异：
- 避免用 Date.now() —— 它只能精确到毫秒，对原始类型转换（通常
- 用 performance.now() 包裹目标操作，重复执行万次取平均值，消除噪声
- 示例：对比
Number(str)、+str、parseInt(str)的开销
注意：务必在相同上下文（如关闭 devtools、禁用扩展）下运行，避免干扰
构造高频循环 + 内存压力场景
原始类型转换的“性能问题”往往不来自转换本身，而来自副作用，比如：
- 字符串转数字后参与大量计算，触发浮点运算瓶颈
- 大量
String(value)或value + ''导致短生命周期字符串对象激增，加重 GC 压力 - 在
for循环内反复调用toString()（尤其对 BigInt、Symbol）
测试时可配合 performance.memory（Chrome）观察堆增长，或用 Node.js 的 --inspect 查看 GC 日志。
用 Benchmark.js 做横向基准对比
当需要严谨比较多种写法（如显式 vs 隐式转换）时，Benchmark.js 提供统计学意义的结论：
- 它自动处理预热、采样、异常值剔除和显著性检验
- 支持直接测试隐式转换场景，例如：
arr[i] + ''vsString(arr[i])vsarr[i].toString() - 输出包括 ops/sec、相对误差、最快/最慢项，比手写循环更可靠
关注真实瓶颈，而非理论开销
实测表明：
-
+str和Number(str)在 V8 中底层高度优化，单次耗时约 0.002–0.005ms（10 万次 ≈ 200–500μs） -
parseInt(str, 10)因需解析前缀和进制逻辑，比Number慢 3–5 倍，但依然远低于 DOM 操作或网络请求量级 - 真正拖慢页面的，通常是转换后引发的后续行为（如用转换结果反复查表、拼接长字符串、触发重排）
所以测试时别只盯着转换函数本身，要还原它所处的真实调用链。
