定时器是节流阀而非加速器，应优先用链式setTimeout动态校准、控制单次≤5ms；结合requestIdleCallback空闲调度；避免定时器内频繁DOM操作；超重任务移交Web Worker。

定时器在密集型计算任务中不是“加速器”，而是“节流阀”——它不缩短总耗时，但能防止主线程卡死，保障页面可交互。关键不在“多用定时器”，而在“用对时机和方式”。

优先用 setTimeout 链式调用，不用 setInterval

setInterval 会盲目触发，若前一次回调还没执行完，后续回调可能堆积或跳过，导致节奏失控、内存泄漏或逻辑错乱。而链式 setTimeout 能在每次任务结束后主动决定下一次何时启动，天然支持动态校准。

• 每次执行前记录时间戳（performance.now()），根据实际耗时调整下次延迟，避免 drift 累积
• 单次任务控制在 3–5ms 内，确保一帧（16.7ms）内能执行 3–5 个单元，留出渲染余量
• 任务完成后才递归调用 setTimeout，杜绝并发重入风险

结合空闲时段调度，让浏览器说了算

比起强行塞进固定间隔，更稳妥的是把任务交给浏览器判断——它知道什么时候真正“空闲”。requestIdleCallback 就是为此设计的，尤其适合后台数据处理、日志聚合等非紧急任务。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 传入 deadline 参数，持续执行 deadline.timeRemaining() > 5 的微任务，自动避开渲染、输入响应等高优阶段
• 设置 timeout 选项（如 { timeout: 2000 }），防止任务被无限搁置
• 注意兼容性：Safari 支持较晚，可降级为 setTimeout(fn, 1) 作为 fallback

避免在定时器里做 DOM 批量更新

定时器本身不阻塞渲染，但频繁、无节制的 DOM 操作会触发重排重绘，反而拖慢整体性能。密集计算 + 频繁 DOM 更新 = 双重压力。

立即学习“Java免费学习笔记（深入）”；

• 把 DOM 更新集中到任务批次末尾，或用 requestAnimationFrame 统一安排在下一帧开始前
• 启用防抖机制：例如用 setTimeout 延迟 100ms 触发最终渲染，避免中间状态反复刷新
• 大量列表渲染优先用 documentFragment 或虚拟滚动，而非逐条 append

超重任务直接交给 Web Worker

当单个计算单元也远超 5ms（比如解析 MB 级 JSON、图像像素处理），定时器分片已不够用——此时主线程不该承担计算，只负责通信和展示。

• 将纯计算逻辑移入 Worker，主线程通过 postMessage 传递数据、接收结果
• Worker 内仍可用 setTimeout 分片，但不影响 UI 响应性
• 注意：Worker 不能访问 DOM，所有 DOM 操作必须回传给主线程执行