浏览器后台标签页定时器降频是标准节能行为，应以服务端时间锚点校准、web worker独立计时、visibilitychange主动补偿及raf渲染替代累加式定时器来保障倒计时准确性与性能平衡。
浏览器对后台标签页的定时器强制降频（如 setInterval 最小间隔拉长至 1000ms）是标准节能行为，不是 bug。应对重点不是“恢复高频”，而是绕过限制、校准逻辑、减少误差累积——核心思路是：不依赖定时器走时，而用时间锚点 + 独立计时 + 可见性响应来保障准确性与性能平衡。
用服务端时间做绝对基准，本地只负责渲染
倒计时不准，根本原因在于把“执行次数”当“流逝时间”。应改用服务器下发的精确时间点作为唯一依据：
- 页面加载时请求 /api/time 获取服务端毫秒时间戳，与 Date.now() 求差，得到 timeDiff
- 所有后续“当前时间”都用 Date.now() + timeDiff 计算，而非靠 setInterval 累加
- UI 更新可用 requestAnimationFrame 或 1s 级 setTimeout，仅做读取+渲染，不参与时间推进
用 Web Worker 维持稳定节奏
主线程被限频，但 Worker 不受页面可见性影响，适合高保真计时场景：
- 新建 countdown-worker.js，内部用 setInterval(1000) 每秒 postMessage 通知主线程
- 主线程监听消息更新 UI，不参与任何计时逻辑，避免闭包持有大对象
- 页面隐藏或关闭前调用 worker.terminate()，防止内存泄漏
监听 visibilitychange 主动补偿偏差
页面切回前台时，往往已滞后数秒。此时不能继续累减，而要立即重算：
- 在 document.addEventListener('visibilitychange') 中判断 document.hidden === false
- 恢复瞬间重新调用服务端时间接口，或直接用本地差值 + 当前 serverTime 推算真实剩余值
- 对用户可见的数字倒计时，可加 CSS 过渡动画（如 transform: scaleY）模拟平滑滚动，掩盖跳变
避免定时器本身成为性能负担
即使前台运行，不当使用也会拖慢主线程：
- 高频 setInterval（如 transform + requestAnimationFrame
- 耗时任务中用 isRunning 标志防回调堆叠，或改用链式 setTimeout 动态校准
- 所有定时器 ID 必须在组件卸载/路由离开时 clearInterval/clearTimeout，否则持续占用内存
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
