是的，Node.js 定时器精度受 GC 显著影响；Full GC 采用 Stop-The-World 策略暂停事件循环，导致 setTimeout/setInterval 回调延迟甚至跳过，暂停可达 100ms～1s，高频 GC 还引发定时器堆积或漂移。
是的，Node.js 中的定时器精度会明显受到垃圾回收（GC）影响，尤其是当发生全堆 GC（Full GC）时。
GC 会直接暂停事件循环
V8 引擎执行 Full GC（如 Mark-Sweep-Compact）时采用 Stop-The-World 策略，即整个 JavaScript 执行线程会被强制暂停。在此期间：
- setTimeout 和 setInterval 的回调不会被调度，即使到期时间已到
- 事件循环停滞，I/O 回调、Promise 微任务等全部等待 GC 完成
- 暂停时间可达 100ms～1s 甚至更长（取决于堆大小和对象复杂度）
GC 频率升高加剧定时器漂移
高频 GC 通常意味着内存压力大，常见于以下场景：
- 短时间内创建大量短生命周期对象（如频繁解析 JSON、生成中间数组）
- 存在隐式内存泄漏（未清理的闭包、全局缓存、事件监听器）
- 新生代空间过小或老生代持续增长，触发更频繁的老代回收
此时定时器不仅单次延迟，还可能出现连续多次“跳过”或“堆积触发”，表现不稳定。
如何验证 GC 对定时器的影响
可通过组合手段观测实际干扰程度：
- 启动时加 --trace-gc --trace-gc-verbose，观察 GC 日志与定时器日志的时间对齐情况
- 用 perf_hooks 同时记录
performance.now()和PerformanceObserver监听的 GC 事件 - 在 GC 高峰期（如批量处理后）运行一个 10ms 间隔的
setInterval，统计实际执行间隔的分布（常出现 100ms+ 峰值）
缓解思路不是禁用 GC，而是减少干扰
无法绕过 GC，但可降低其对定时敏感逻辑的冲击：
- 避免在定时器回调中分配大对象或触发深层计算（防止回调自身成为 GC 诱因）
- 对精度要求高的场景（如音频同步、实时采样），改用 process.hrtime.bigint() + 主动轮询判断，不依赖回调时机
- 通过 --max-old-space-size 合理设置堆上限，避免 GC 突然膨胀；用 node-gc-profiler 定位回收热点
- 关键服务中，将定时逻辑与内存密集型任务错开，例如用
setImmediate或微任务让出当前 tick
