原始类型操作本身高效，但不当使用会引发装箱开销、隐式转换破坏JIT优化、原型污染导致内联缓存失效、数字精度误用增加冗余转换；应优先用字面量运算、严格相等、冻结原型、整数化处理。
JS 原始类型本身轻量高效，但操作方式不当会悄悄拖慢性能——尤其在高频循环、渲染逻辑或数据密集场景中。这些风险不报错、不卡死，却让帧率下降、GC 频繁、响应变慢。
装箱开销：看似无害的方法调用
原始值（如 "hello"、123）调用方法时，JS 会临时创建包装对象（如 String 或 Number 实例），执行完再销毁。单次无感，循环中则成倍放大：
- ❌
arr.forEach(n => n.toString().padStart(4, '0'))—— 每个数字都被装箱 → 调方法 → 拆箱 → 创建新字符串 → GC 回收 - ✅ 改为
arr.map(n => (n + '').padStart(4, '0'))或先转字符串再处理，跳过构造函数调用路径 - ⚠️ 注意：
str.toUpperCase()、num.toFixed(2)同样触发装箱；若只需判断或简单计算，优先用字面量运算（如str === 'abc'、num | 0）
隐式转换：运行时多走一步，V8 难优化
用 ==、+ 拼接数字、!value 判断等，会让引擎在每次执行时做类型推断和转换，破坏 JIT 编译器的优化假设：
- ❌
if (status == 200)→ 先查status类型，再尝试转数字或字符串，分支预测易失败 - ✅ 改为
if (status === 200)，直接比值+类型，V8 可内联、可常量折叠 - ❌
'' + num虽快，但若num是null或undefined，结果变成"null"或"undefined"—— 需兜底 - ✅ 明确意图：
String(num)更安全；金额等关键场景，用num?.toString() || '0'
原型污染带来的间接损耗
第三方脚本篡改 String.prototype 或 Number.prototype 后，不仅逻辑错乱，还会干扰引擎内联缓存（IC）：
- 原本
'a'.charAt(0)可被 V8 快速命中内联缓存，一旦原型被加/改方法，缓存失效，回退到慢路径查找 - 冻结能防住后续污染：
Object.freeze(String.prototype)应在入口尽早执行 - ⚠️ 冻结不能修复已发生的污染，所以必须早于所有第三方脚本加载
数字精度误用：小数运算反复装箱+重算
0.1 + 0.2 !== 0.3 不只是逻辑陷阱，更是性能坑：
- 为“修正”浮点误差，有人写
parseFloat((a + b).toFixed(10))——toFixed装箱 → 返回字符串 →parseFloat再解析 → 两次转换 - ✅ 整数化处理：金额存分为单位，
priceCents = Math.round(price * 100)，全程整数运算 - ✅ 高频比较用
Math.abs(a - b) ，避免字符串来回转
