javascript定时器时间漂移本质是设计使然：setinterval只保证尽可能按间隔执行。需用performance.now()时间戳动态校准，结合visibilitychange监听页面可见性，并锚定服务器时间同步时钟偏差，避免多定时器叠加与最小延迟陷阱。
JavaScript 中长时间运行定时器出现时间漂移，本质不是“定时器坏了”，而是它被设计成这样——setInterval 不保证准时，只保证“尽可能按间隔重复”。每次回调执行耗时、主线程卡顿、页面切后台、系统节流，都会让实际触发时间晚于预期。久而久之，误差叠加，10分钟可能差出好几秒。
用时间戳动态校准，而不是固定间隔
放弃 setInterval 的“机械循环”逻辑，改用 setTimeout 递归 + 时间戳比对：
- 启动时记录基准时间（如
startTime = performance.now()） - 每次回调中计算“本该执行的时间点”：
expected = startTime + count * interval - 算出当前已延迟多少：
drift = performance.now() - expected - 下一次延迟设为：
Math.max(0, interval - drift)，自动补回偏差
主动感知页面可见性变化
浏览器在标签页不可见时会大幅降频甚至暂停定时器，仅靠 drift 校准无法恢复丢失的 tick：
- 监听
document.visibilitychange，页面隐藏时记下hiddenAt = Date.now() - 恢复可见时，计算休眠时长
now - hiddenAt - 把这段“静默时间”直接从倒计时里扣除，或加到下次目标时间上
- 这对秒杀倒计时、直播进度同步等场景至关重要
锚定服务器时间，绕过本地时钟风险
用户可随意修改系统时间，导致所有 Date.now() 计算失效：
- 初始化时请求一次
/api/time获取服务端时间戳 - 计算客户端与服务端时间差：
offset = serverTime - Date.now() - 后续所有“应该发生的时间点”都基于
serverTime + offset + elapsed推算 - 每 30–60 秒轻量同步一次 offset，抵消网络延迟或服务端漂移
避免多定时器叠加和最小延迟陷阱
看似无关的操作，也可能放大漂移：
- 多次点击启动按钮却未清除旧定时器 → 多个定时器并行 → 表现为“越走越快”
- 在非活跃标签页中，浏览器会将 setTimeout/setInterval 最小延迟强制拉长至 1000ms
- 嵌套调用超过 5 层时，Chrome/Firefox 会将最小延迟限制为 4ms，影响高频任务
- 回调函数本身耗时过长（如重绘、大量计算），会直接挤占下一次执行窗口
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
