JavaScript定时轮询存在五大性能瓶颈：异步调用栈嵌套、定时器精度不可靠且被降频、回调阻塞主线程、DOM操作未优化引发重排重绘、内存泄漏与资源滞留。
JavaScript 定时轮询看似简单，但实际运行中容易触发多个隐蔽的性能瓶颈。问题不在于“有没有定时器”，而在于“怎么用”——尤其当轮询持续数分钟甚至数小时时，这些瓶颈会逐级放大，影响响应、内存和可观测性。
异步调用栈持续累积
递归式 setTimeout + async 函数 是典型陷阱：每次回调里立刻调用 setTimeout(poll, interval)，会导致浏览器异步堆栈追踪（Async Stack Traces）不断嵌套。虽然不会真正栈溢出，但：
- 调试时
console.trace()显示层层嵌套的poll → start → poll → start…，掩盖真实执行路径 - 长期运行后，异步帧数量线性增长，占用额外内存与调试开销
- 逻辑上形成隐式嵌套——新轮询在上一轮尚未完全退出时就已注册，违背“最小间隔”设计本意
定时器精度不可靠且被主动降频
定时器本质是“最小延迟触发器”，不是倒计时钟。它的实际触发时间受多重干扰：
- 事件循环阻塞：主线程忙于渲染或计算时，回调可能延迟几十毫秒甚至更久
- 浏览器节流策略：后台标签页中，Chrome/Firefox 将最小间隔强制拉高至 1000ms；连续嵌套达 5 层以上，delay 被抬升至 ≥4ms
- 系统级抖动：CPU 调度粒度、GC 暂停、DRAM 访问延迟、节能模式等，都会造成毫秒级偏差
回调执行阻塞主线程
轮询回调若包含同步重操作（如解析大 JSON、遍历万级数组、频繁 DOM 写入），会直接变成“长任务”：
立即学习“Java免费学习笔记（深入）”；
- 单次执行超 50ms，用户就能感知卡顿；超 100ms，交互明显滞后
- 若轮询间隔短（如 500ms），而回调常耗时 300ms，实际轮询节奏将严重失序，甚至出现回调堆积
- DOM 操作未批量处理或未用
documentFragment，会反复触发重排/重绘，进一步拖慢执行
内存泄漏与资源滞留
轮询常伴随状态维护与外部引用，稍不注意就会累积泄漏：
- 未清除的定时器本身虽不占大内存，但若其回调闭包持有大型数据或 DOM 引用，会阻止垃圾回收
- 轮询中重复创建对象、监听器、Promise 实例却未释放，导致堆内存持续上涨
- 页面卸载或组件销毁后，忘记
clearTimeout/clearInterval，使定时器继续运行并维持所有上下文
