<p>Array.from() 不涉及 Java/C# 意义的装箱，其所谓“原始类型临时装箱”实为轻量级、栈内完成的临时对象包装，无堆分配、无 GC 压力；真正性能瓶颈在于显式创建对象或频繁 DOM 方法调用。</p>
Array.from() 本身不涉及 Java 或 C# 意义上的“装箱”（boxing），它是一个纯 JavaScript 方法，作用是将类数组或可迭代对象转为真数组，并支持在转换过程中对每个元素做映射处理。所谓“原始类型临时装箱开销”，其实是误用概念造成的性能误解——JavaScript 中的原始值（如 number、string、boolean）在被当作对象调用方法时（例如 5.toString()），引擎会**临时包装成对应包装器对象**（如 new Number(5)），这个过程叫“临时对象包装”，不是 JVM 或 CLR 那种堆分配意义上的装箱。
为什么说这不是真正的“装箱开销”？
JavaScript 的原始值包装是轻量、栈内完成、无 GC 压力的内部机制：
• 包装器对象不实际分配在堆上，多数情况下由引擎优化跳过构造；
• 不触发垃圾回收，也不产生内存泄漏风险；
• 不同于 Java 的 Integer.valueOf()，JS 中没有缓存区间判断或对象复用逻辑；
• 即使写 Array.from([1,2,3], x => x.toFixed(1))，也只在需要调用方法时瞬时包装，且立即丢弃。
真正影响性能的其实是“不必要的对象创建”
当映射函数中显式创建新对象（比如返回一个 {value: x}），或频繁访问 DOM 节点属性（触发重排/重绘），这才是实际瓶颈。原始值本身参与计算（x * 2、String(x)）几乎零成本。
如何写出高效、无冗余的 Array.from 映射？
• 尽量用纯函数式操作：直接返回原始值或字符串，避免构造对象
示例： Array.from('123', Number) ✅ 比 Array.from('123', c => ({num: Number(c)})) ❌ 快得多
• 对 DOM 节点批量提取，优先用属性访问而非方法调用
示例： Array.from(buttons, btn => btn.id) ✅ 比 Array.from(buttons, btn => btn.getAttribute('id')) ❌ 更快（后者多一次方法查找与调用）
• 若需多次使用同一节点信息，先解构再复用，减少重复属性读取
示例： Array.from(items, ({offsetWidth, offsetHeight}) => offsetWidth * offsetHeight)
什么时候该担心“包装”？基本不用
除非你在循环中反复执行类似 for (let i = 0; i 这类强制包装 + 字符串化操作（且已确认是性能热点），否则无需干预。现代 JS 引擎（V8、SpiderMonkey）对此类模式有深度优化，实际耗时通常低于纳秒级。
