高频中断中定义匿名生成器会频繁触发Minor GC，拖垮帧率；应复用生成器实例、显式传参、避免捕获大对象，并可用WASM或环形缓冲区优化。
直接在高频中断（比如每毫秒触发的 requestAnimationFrame、触摸事件、传感器回调）中定义匿名生成器，会持续创建新生成器对象和闭包环境，迅速填满年轻代（Eden 区），导致每几毫秒就触发一次 Minor GC。这种抖动不是“GC 慢”，而是“GC 太勤”——停顿虽短，但密度高，直接拖垮帧率。
复用生成器实例，避免每次中断都 new
生成器函数本身可复用，关键在于别在中断回调里反复调用 gen() 创建新实例：
- 把生成器函数提前定义好，中断中只调用
.next()或.send()，不重新构造 - 若需状态隔离（如多个并行动画），用
class封装生成器逻辑 + 实例字段，而非靠闭包捕获局部变量 - 避免在生成器内部
yield大对象（如数组、JSON 解析结果），改用预分配缓冲区或结构体复用
禁用闭包捕获，切断隐式对象链
匿名生成器常依赖外层变量，一旦捕获，就会生成闭包对象并延长生命周期：
- 把中断处理所需数据显式传入生成器（如
gen(state)），而不是让它从作用域链读取 - 不要在生成器内引用
this、event或 DOM 元素——这些对象体积大、生命周期难控 - 用
const声明的字面量（数字、字符串、小对象）可安全捕获；但数组、函数、DOM 节点一律避免
配合手动控制 GC 节奏（仅限必要场景）
浏览器 JS 引擎不暴露 GC 接口，但可通过行为引导减少抖动：
- 在中断密集期（如动画启动后 200ms）主动触发一次
performance.memory.gc?.()（Chrome 实验性 API，仅开发调试用） - 更可靠的做法：在中断空闲窗口（如
setTimeout(() => {}, 0)）批量清理临时缓存，让 GC 在非关键帧发生 - 对固定模式的数据流（如传感器采样），用环形缓冲区替代每次
yield [...]，避免数组重复分配
用 WebAssembly 或 SharedArrayBuffer 做底层状态管理
当 JavaScript 层抖动已难以收敛，可将高频状态更新下沉：
- 用 WASM 模块维护计数器、滑动窗口、插值状态等，JS 层只做低频同步
- 借助
SharedArrayBuffer+Atomics在 Worker 中持续写入采样数据，主线程按需读取，避开 JS 堆分配 - 注意：WASM 模块内仍需避免频繁 malloc/free；优先用线性内存预分配 + 索引偏移访问
