原始类型转换无内存开销，真正影响性能的是显式创建包装对象（如new string）或高频字符串拼接；临时包装如"abc".touppercase()由引擎优化，不分配堆内存；类型判断优先用typeof而非instanceof；字符串拼接宜用数组join或模板字面量；array.from映射应保持纯函数，避免显式对象创建或dom调用。
原始类型转换本身几乎没有内存开销，真正影响性能的是不当的对象创建或重复包装行为。
原始值调用方法时的“临时包装”不等于装箱
JavaScript 中像 "abc".toUpperCase() 或 123.toString() 这类操作，引擎不会真正构造 String 或 Number 对象。它只是在内部快速映射到原型方法，执行完立即丢弃，不分配堆内存，也不触发垃圾回收。V8 等现代引擎还会将这类调用编译为内联字节码，实际耗时通常低于纳秒级。
显式创建包装对象才带来真实开销
只有使用 new String("x")、new Number(42) 或 Object(3.14) 才会生成真实对象：需堆分配、执行构造函数、绑定原型链，并增加 GC 压力。微基准测试显示，new Number(123) 比字面量 123 慢 5–10 倍。
- 避免在循环或高频路径中写 for (let i = new Number(0); i
- 类型判断优先用 typeof x === "string"，而非 x instanceof String（后者需遍历原型链）
字符串拼接与不可变性带来的隐性成本
字符串是原始类型，但不可变。每次 str += "a" 或 "hello" + name 都会创建新字符串，旧字符串变成待回收垃圾。高频拼接（如日志组装、模板生成）可能推高 GC 频率，引发主线程暂停。
- 大量拼接优先用数组 .push().join("") 或 String.raw 模板字面量
- 避免在深层循环中反复做 String(x) + y + z，可先转再拼
Array.from 映射中的常见误判点
Array.from([1,2,3], x => x.toFixed(1)) 不构成性能瓶颈——toFixed 触发的临时包装由引擎优化，无需担心。真正拖慢的是映射中显式创建对象，比如返回 { value: x }，或反复调用 getAttribute 等 DOM 方法。
- 保持映射函数纯：直接返回原始值、字符串或数字计算结果
- 提取 DOM 属性优先用 btn.id 而非 btn.getAttribute("id")
- 需多字段时先解构：Array.from(items, ({ offsetWidth, offsetHeight }) => offsetWidth * offsetHeight)
