copyWithin不触发GC，因其绕过堆内存分配、不创建新对象，仅原地复制值或引用指针，无新增待回收对象；V8等引擎直接操作底层线性内存区，用类似memmove指令批量位移，空间复杂度O(1)，零分配、零GC介入。
copyWithin 的“不产生新垃圾”不是修辞，而是它绕过堆内存分配、不创建任何新对象的直接体现——它只读写已有数组的连续内存块，因此不会向垃圾回收器提交任何待清理对象。
为什么它不触发 GC
JavaScript 引擎（如 V8）对 copyWithin 做了底层优化：它跳过常规属性访问路径，直接操作数组底层的线性内存区域（比如 FastElements 存储区），用类似 memmove 的指令批量搬运数据。整个过程：
- 不 new 任何数组、不构造新元素、不封装包装对象
- 对原始类型（数字、字符串等）复制的是值本身，无引用生成
- 对对象或数组等引用类型，只复制指针地址，原对象仍由原引用持有，不新增强引用
- 不改变数组 length、不修改稀疏性、不调整内部结构体，无元数据变更开销
对比其他方法的垃圾压力
同样实现“把后三个元素移到开头”，不同写法的内存行为差异显著：
-
arr = [...arr.slice(-3), ...arr.slice(0, -3)]：创建两个新子数组 + 一个新结果数组 → 3 个新对象，全部进新生代，很快触发 Minor GC -
arr.splice(0, 0, ...arr.splice(-3))：多次重排、隐式扩容、内部临时数组 → 至少 2–4 次堆分配 -
arr.copyWithin(0, -3); arr.copyWithin(3, 0, arr.length - 3)：零分配，仅两轮内存块位移，无 GC 介入可能
真实场景中的收益点
在持续高频更新的数据流中，“不产生新垃圾”直接转化为可预测的运行时表现：
- 滚动日志缓冲区每秒调用数百次 copyWithin，内存占用恒定，GC 暂停时间趋近于零
- WebGL 纹理坐标数组做滑动窗口更新，避免因频繁分配导致的帧率抖动
- 音频处理中对 float32Array 进行环形写入，CPU 缓存友好，无 GC 抢占实时线程
它的优势不在单次快多少，而在于长期稳定——没有新对象，就没有回收负担；没有分配，就没有碎片与延迟波动。
