倒计时不准的根本原因是依赖本地时间而非服务端统一时间戳；应以 serverTime 初始化，并定期校准，用 requestAnimationFrame 或带整秒判断的 setInterval 更新，隐藏时暂停并恢复时重新校准，结束时通过事件解耦处理，iOS 低版本需降级兼容。
倒计时不准？检查 Date 时间源是否本地化
浏览器用 new Date() 获取的是用户本地时间，不是服务器时间。一旦用户手动调快/调慢系统时钟，倒计时就直接失真——比如显示“还剩 5 秒”，实际已过期 2 分钟。这不是 JS 写错了，是时间基准错了。
- 上线前必须用服务端返回的统一时间戳（如
serverTime: 1717023600000）初始化倒计时，而不是new Date() - 前端每 10–15 秒可再请求一次服务端时间，做一次小幅度校正（避免频繁请求），用差值微调当前倒计时毫秒数
- 别依赖
setTimeout累加来算剩余时间，它受页面休眠、CPU 负载影响；应每次用「目标时间戳 - 当前校准后时间戳」实时计算
setInterval 更新倒计时的最小安全间隔是多少
设成 1000 毫秒（1 秒）看似合理，但实际可能跳秒或卡顿：页面切到后台时，Chrome 会把 setInterval 节流到最低 1 秒甚至更久；动画帧不触发，innerHTML 更新滞后。
- 推荐用
requestAnimationFrame+ 时间差计算：每帧检查「当前校准时间」离截止还有多久，再格式化输出，视觉更顺滑 - 如果坚持用
setInterval，间隔设为500毫秒，并在回调里判断是否整秒（Math.floor(remaining / 1000) !== lastSecond），只在整秒时更新 DOM - 务必在页面隐藏（
visibilitychange）时暂停定时器，切回可见时重新校准并恢复，否则后台跑久了误差会累积
倒计时结束时不执行跳转或按钮禁用？查 DOM 更新时机
常见现象：控制台打印出 “end”，但按钮还是能点、跳转没发生。往往是因为你写了 if (remaining ，却没考虑 DOM 更新和 JS 执行顺序。
- 不要在倒计时循环里直接改
location.href—— 浏览器可能还没渲染完禁用状态就跳走了，用户看到“点了没反应” - 正确做法：先置
btn.disabled = true，再用setTimeout(() => { location.href = '/pay' }, 16)延迟到下一帧之后执行跳转 - 更稳妥的是监听倒计时结束事件（自定义
Event），由外部模块统一处理后续动作，解耦渲染逻辑和业务逻辑
移动端 Safari 倒计时卡死？注意 requestAnimationFrame 兼容性
iOS 15.4 之前，Safari 在页面非活跃标签页或锁屏后，requestAnimationFrame 会完全停止，导致倒计时“冻结”。而用户回来时发现已超时，体验极差。
立即学习“前端免费学习笔记（深入）”；
- 降级方案：检测到
requestAnimationFrame不可用（如 iOS setInterval(fn, 500)，并配合 visibilitychange 做启停 - 用
document.hidden+visibilitychange事件，在页面隐藏时记录暂停时刻，在显示时用服务端时间补算已流逝时长，再更新剩余时间 - 别省略
clearInterval或cancelAnimationFrame：组件卸载、倒计时结束、用户离开页面时都得清理，否则内存泄漏+后台无效轮询
真实项目里最常被忽略的，是服务端时间与客户端时间之间的网络延迟补偿——哪怕只有 200ms，对秒级抢购也足以让一批用户“以为没抢到”而反复点击。这个量级没法靠 JS 抵消，得在接口设计时就约定好时间戳字段语义和误差容忍窗口。
