V8引擎采用增量标记将长耗时的全量标记拆分为多个≤5ms的小任务，穿插在主线程空闲时执行，避免单次暂停超16ms导致掉帧卡顿。
现代 JS 引擎（如 V8）不会等页面卡住才开始垃圾回收——它用 增量标记 把一次长耗时的全量标记拆成多个小任务，穿插在 JavaScript 主线程空闲时执行。这不是“不挂起”，而是“不明显挂起”；关键在于调度时机和暂停时长控制。
为什么全量标记会卡住页面
传统 标记-清除 的标记阶段需遍历整个堆中所有可达对象，若堆中有数万甚至数十万个对象，单次遍历可能持续几十毫秒。而浏览器主线程每帧只有约 16ms（60fps）来完成样式计算、布局、绘制和 JS 执行——一旦标记占用超过这个阈值，用户就会感知到掉帧、输入延迟或动画卡顿。
常见错误现象包括：滚动突然卡顿、setTimeout 回调延迟明显、input 输入响应变慢，且这些现象常在大量对象创建/销毁后集中出现（比如列表快速渲染再清空）。
根本原因不是内存大，而是标记过程阻塞了事件循环，让 requestAnimationFrame、用户交互、网络回调全部排队等待。
增量标记 是怎么拆分和调度的
V8 在进入 GC 周期后，并不一次性跑完标记，而是把对象图遍历切成小块（通常按对象数量或时间预算，如 5ms），每次只处理一块，然后主动让出主线程控制权。
- 每次标记前检查是否临近下一帧 deadline（通过
performance.now()或内部高精度时钟） - 标记一小批对象后，立即返回事件循环，允许
click、scroll、fetch回调执行 - 下一次主线程空闲时（比如微任务队列清空后、宏任务间隙），继续标记下一批
- 整个过程可能横跨数十甚至上百次事件循环周期，但单次暂停严格控制在 1–5ms 内
示例行为：你在快速滚动一个虚拟滚动列表，V8 可能在第 1 次空闲时标记 200 个 DOM 节点关联对象，第 2 次空闲时标记 180 个闭包变量，第 3 次处理完剩余引用链——你完全感知不到。
哪些操作会触发或干扰增量标记
增量标记不是独立运行的魔法，它依赖引擎对“何时安全暂停”的判断。以下情况会显著影响其效果：
- 长时间同步脚本（如
for循环 >10ms）会挤压空闲窗口，导致标记积压，最终退化为一次长暂停 - 频繁调用
console.log（尤其打印大型对象）会临时增加堆压力，也可能打断增量节奏 - 使用
WeakRef或FinalizationRegistry会引入额外标记路径，延长整体周期 - 在
requestIdleCallback中手动触发gc()（仅限调试版 V8）可强制推进，但生产环境不可用
真正影响体验的，往往不是 GC 本身，而是你写的代码没给引擎留出空闲机会——比如用 while(Date.now() - start 模拟忙等，就等于锁死了增量标记的入口。
开发者能观察到的线索很有限，但有迹可循
你无法直接读取“当前增量标记进度”，但可通过 Chrome DevTools 的 Performance 面板录制并筛选 GarbageCollection 事件，观察其是否被拆分为多个短条（类型为 MinorGC 或 MajorGC 后带 “Incremental” 标签）。
更实用的判断方式是看 Tasks 时间轴里是否出现密集的、Scavenger 和 Marking 任务），它们穿插在你的 JS 任务之间——这就是增量标记正在工作。如果只看到一个 >20ms 的长条，说明某次标记被迫合并执行了，大概率是你刚做完一件重活（比如解析大 JSON + 构建千级对象树）。
真正容易被忽略的是：增量标记只解决“标记阶段”的阻塞，清除和整理阶段仍可能造成短暂停顿；而如果你的代码持续制造大量短命对象（如在 mousemove 中反复创建对象字面量），即使增量标记再平滑，GC 频率上升本身也会吃掉 CPU 时间片——这时候该优化的不是 GC，是你的对象复用策略。
