微任务调度不受V8 GC直接干预，但GC执行时机和开销会间接影响其响应及时性；GC只能在宏任务结束与微任务执行完毕之间的空闲窗口触发，且会暂停JS执行从而延迟下一轮微任务清空。
微任务调度本身不直接受 V8 垃圾回收（GC）触发或干预，但 GC 的执行时机和开销会间接影响微任务的响应及时性与整体执行节奏。
微任务执行时机是固定的，GC 不会打断它
在事件循环中，微任务队列总是在当前宏任务执行完毕、调用栈清空后立即被清空——这个过程是强制、同步、不可中断的。V8 不会在微任务执行中途插入 GC；即使 GC 已就绪，也必须等所有微任务全部执行完才可能启动。
也就是说：微任务的调度逻辑完全由事件循环规则决定，GC 不参与调度决策，也不抢占微任务的执行权。
GC 会抢占“微任务之间的空隙”和“宏任务切换窗口”
虽然 GC 不打断正在运行的微任务，但它高度依赖主线程的空闲时间。这些关键空闲点恰好也是微任务机制的“承上启下”位置：
立即学习“Java免费学习笔记（深入）”；
- 当前宏任务结束 → 清空微任务队列前：极短间隙，通常不足以触发 GC
- 所有微任务执行完毕 → 下一个宏任务开始前：这是 GC 最常介入的窗口
- 长时间同步任务阻塞主线程 → 彻底剥夺 GC 机会，导致内存压力累积，间接拖慢后续微任务的准备环境（如 Promise 构造、回调入队等）
一旦 GC 在该窗口启动（尤其是老生代的标记-清除或标记-整理），它会暂停 JavaScript 执行（Stop-The-World），延迟下一个宏任务的开始，也就推迟了下一轮微任务队列的清空时机。
高频 GC 会让微任务“感觉变慢”，尤其在内存紧张时
当新生代频繁填满（比如大量短生命周期对象持续创建），Scavenge 回收会高频触发。虽然单次很快，但叠加微任务本身的入队/执行开销（如 Promise.then 创建微任务、解析回调函数），整体响应会出现可测的延迟抖动。
更明显的情况是：若某次微任务中分配了大量对象（例如批量处理数组生成新对象），紧接着触发新生代 GC，那么下一轮微任务的执行起点就会被推后——不是微任务被跳过或重排，而是整个事件循环节奏被 GC 拉长。
优化方向：减少 GC 对微任务流的干扰
让微任务保持轻量、可预测，本质上就是为 GC 创造稳定空闲窗口：
- 避免在单个微任务中创建大量临时对象（如不用 Array.from(new Array(10000)) 构造大数组）
- 及时切断闭包引用、移除事件监听器、清空定时器，防止本该被回收的对象滞留在老生代
- 对计算密集型逻辑，用
queueMicrotask拆成小块，比堆满一个微任务更利于 GC 插入 - 大对象（如 ArrayBuffer、大型 JSON 解析结果）尽量直接进入老生代，避开新生代高频复制压力
不复杂但容易忽略。
