移动端JS应适配V8垃圾回收机制：按生命周期分配对象、控制晋升节奏、协同内存边界、规避写屏障误触发，以减少GC停顿、避免掉帧卡顿。
移动端 JavaScript 应用对内存更敏感——设备 RAM 有限、后台常被系统回收、电池与热限制严苛。V8 的垃圾回收启发式算法（如分代假设、对象晋升阈值、写屏障触发时机）不是黑盒，而是可被应用策略反向利用的信号源。关键不在于“对抗 GC”，而是让代码行为与 V8 的默认启发式高度对齐。
按生命周期分配对象，匹配新生代设计
V8 新生代空间小（通常 1–8 MB）、GC 频繁但极快（Scavenge 复制开销低）。移动端高频交互中产生的临时对象（如事件参数、计算中间值、短时缓存键）应尽量保持“即用即弃”形态：
- 避免在闭包中长期持有局部对象引用，防止本该快速回收的对象被意外晋升
- 手动解除大数组/对象的引用（如 arr = null、obj.cache = null），尤其在页面切换或组件卸载时
- 用字面量（{}、[]）替代重复 new Object() 或 new Array()，减少构造开销并利于 V8 快速识别短命特征
控制晋升节奏，减少老生代压力
对象在新生代经历约 2 次 Scavenge 后若仍存活，会被晋升至老生代。而老生代 GC（Mark-Sweep/Mark-Compact）停顿长、代价高，在低端安卓机上一次 full GC 可达 50–200ms，直接引发掉帧或卡顿：
- 避免无意义的“预热引用”：例如提前创建一个空对象并挂到全局或长期存活组件上，即使暂未赋值，也会因根可达而阻止晋升延迟
- 对需复用的数据结构（如池化对象），显式管理生命周期，用 reset() 清空内部状态而非重建，使其持续驻留新生代而非反复进出
- 慎用 setTimeout(fn, 0) 或微任务包裹短期对象——微任务队列会延长对象存活时间，易触发提前晋升
适配移动端内存边界，主动协同 V8 限界
V8 在移动 WebView 或 Capacitor/Cordova 环境中仍沿用默认内存上限（64 位约 1.4 GB），但实际可用内存远低于此。系统可能在总内存 70% 时就触发网页进程降级甚至 kill：
- 监听 memoryInfo（如 Chrome WebView 的 performance.memory，或通过 process.memoryUsage() 在 Capacitor 中桥接）做软性水位预警
- 当 heapUsed / heapTotal > 0.65 时，主动触发轻量级清理：清空非关键缓存、释放离屏 DOM、暂停非视觉动画逻辑
- 不依赖 --max-old-space-size 参数调优（移动端无法启动参数），转而用业务逻辑节流替代：例如将批量数据处理拆为 50ms 分片，每片后 await Promise.resolve() 让出主线程，为增量标记（Incremental Marking）创造执行窗口
规避写屏障误触发，降低 GC 频次
V8 对老生代对象写入新生代引用时插入写屏障（Write Barrier），用于追踪跨代引用。频繁更新老对象的属性（如全局配置对象、单例状态树）会增加屏障开销：
- 将高频变更字段（如计数器、开关标志）抽离为独立小对象，使其落在新生代，避免污染老生代对象头
- 用 Object.freeze() 或 const 声明真正不变的配置对象，帮助 V8 静态推断不可变性，减少屏障检查
- 避免在循环中反复修改同一对象的多个属性（如 item.a=1; item.b=2; item.c=3），改用解构赋值一次性替换：item = {...item, a:1, b:2, c:3}，让旧对象更快不可达
