v8引擎对展开运算符的快速路径优化，核心是当展开对象为字面量数组、尾部展开或具有稳定隐藏类时，跳过通用迭代直接生成高效机器码；否则回退至开销较大的symbol.iterator遍历路径。
JS 引擎对字面量中展开运算符（...）的内联编译优化，核心在于：当展开操作出现在数组或对象字面量的**特定位置**，且被展开的是**已知结构、长度稳定、可静态推断的数组/类数组**时，V8 等现代引擎会跳过通用迭代路径，直接生成高效机器码——这叫“快速路径”（fast-path）。
为什么需要专门优化展开运算符？
展开本质上是迭代 + 复制。不加优化时，引擎必须：
- 调用被展开对象的
[Symbol.iterator]方法 - 反复执行
iterator.next()，逐个取值 - 动态扩容目标数组，每次插入都可能触发内存重分配
这个过程开销大，尤其在高频调用场景（如渲染循环、大量数据拼接）下明显拖慢性能。
内联编译如何触发快速路径？
关键条件不是“写法多酷”，而是“引擎能否在编译期确定行为”。满足以下任一情况，V8（Chrome 72+）更可能启用快速路径：
-
展开对象是字面量数组：例如
[...[1, 2, 3], 4]—— 引擎知道长度是 4，元素确定，直接展开为[1, 2, 3, 4] -
展开位置靠后（尾部）：如
[a, b, ...arr]比[...arr, a, b]更易优化，因引擎可先预留空间再填入 arr 元素 -
被展开变量有稳定隐藏类（hidden class）且长度不变：比如反复用同一个固定长度的
const fixed = [10, 20];展开，JIT 编译器会缓存其结构信息
哪些写法会绕过快速路径？
一旦引入不确定性，引擎就退回通用迭代逻辑：
- 展开动态生成的数组：
[...getArray(), 5]（getArray()返回值不可预判） - 展开含 getter 或代理对象：
[...new Proxy([1], {...})] - 展开稀疏数组或含空位：
[...[, , 3]]（需特殊处理空位语义） - 在非字面量上下文中使用：
return [...arr]（函数返回值无法静态分析）
开发者能做什么？
不需要手写汇编，但可以主动配合引擎：
- 优先用字面量构造已知结构的数据，再展开：
const base = [1, 2]; const full = [...base, 3, 4]; - 避免在热代码中展开不确定长度的变量；若必须，考虑提前
Array.from()或slice()转为稳定结构 - 用
console.time()对比[...arr, x]和[x, ...arr]在 Chrome 中的实际耗时（注意：Safari/Firefox 无此差异）
