高并发web应用中定时器易成性能瓶颈，优化需以时间戳驱动、web worker减负、主动校准可见性变化、收敛调度入口为核心策略。
高并发 Web 应用中，定时器不是“设了就能准”，而是容易成为性能瓶颈的隐性源头——主线程阻塞、回调堆积、后台降频、内存泄漏都可能集中爆发。优化核心不是调高频率，而是让时间逻辑脱离执行节奏，用更可控的方式调度与校准。
用时间戳驱动，而非依赖定时器间隔
定时器本身不保证准时，尤其在多任务并行时，setInterval(100) 可能实际每 300ms 才执行一次。真正可靠的是真实流逝的时间：
- 记录起始服务端时间戳（如 /api/time 返回的毫秒值），本地只做差值计算
- 倒计时渲染用 Date.now() + timeDiff 得到当前服务端时间，再算剩余秒数
- 轮询类任务改用递归 setTimeout，每次根据 Date.now() 动态计算下次触发时机，避免误差累积
主线程减负：用 Web Worker 独立计时
后台标签页中，主线程定时器会被浏览器强制限频至最低 1000ms；但 Web Worker 不受页面可见性影响，适合维持稳定节奏：
- 在 worker 中启动 setInterval(1000)，每秒 postMessage 通知主线程更新 UI
- 主线程仅负责接收消息、读取状态、渲染，不参与任何时间推进逻辑
- 页面隐藏前调用 worker.terminate()，防止长期驻留导致内存泄漏
主动响应可见性变化
用户切回前台时，定时器往往已滞后数秒。此时不能继续“硬减”，而要立即重校准：
- 监听 document.addEventListener('visibilitychange')
- 当 document.hidden === false 时，重新请求服务端时间或基于本地差值推算真实剩余值
- 对 UI 层倒计时数字，可加 CSS 过渡动画（如 transform: scaleY）缓和跳变感
收敛调度入口，避免定时器泛滥
上百个独立 setInterval 比一个集中调度器更耗资源。推荐分层收敛：
- 用单个 requestAnimationFrame 或 setTimeout(0) 驱动所有子任务，按优先级排序执行
- 紧急任务（如用户反馈）走 queueMicrotask；非紧急任务（如日志聚合）延至 requestIdleCallback
- 对可能重复触发的回调加 isRunning 标志或锁机制，防重入导致状态错乱
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
