用 setTimeout 递归调用更可靠。因 setInterval 在页面切走或休眠时易累积误差，而 setTimeout 每次基于 date.now() 动态校准；倒计时终止条件应为 remainingMs ≤ 0，及时清定时器并更新 ui，避免卡在 00:00:01 或超时仍可点击。
倒计时逻辑用 setInterval 还是 setTimeout？
用 setTimeout 递归调用更可靠。浏览器标签页切走或系统休眠时，setInterval 容易累积误差甚至跳过多次回调；而 setTimeout 每次都基于当前时间重新计算剩余毫秒，能动态校准。
实操建议：
- 每次触发后，用
Date.now()获取当前时间，和目标时间做减法，得到真实剩余毫秒 - 不依赖“每秒减一”的累加逻辑，避免因执行延迟导致倒计时不准
- 清除定时器必须用对应的
clearTimeout（配setTimeout）或clearInterval（配setInterval），混用会失效
如何处理倒计时结束后的状态更新？
倒计时归零不能只靠“剩余秒数 === 0”判断，因为浮点误差或执行延迟可能导致跳过 0，直接变成负数。应以剩余毫秒 ≤ 0 为终止条件，并立即清除定时器、更新 UI。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 倒计时卡在
00:00:01不变，实际已超时 - 按钮仍可点击，但接口返回
400 Bad Request（如活动已结束）
正确做法：
- 检查
remainingMs 后，立刻clearTimeout(timerId) - 同步禁用按钮、隐藏倒计时区域、显示“已结束”文案
- 如有后续动作（如跳转、弹窗），放在清除定时器之后执行，避免竞态
格式化显示时要注意哪些兼容性细节？
String.prototype.padStart() 在 IE 中不支持，若需兼容旧浏览器，得手写补零逻辑；另外，不同单位换算容易出错，比如误把毫秒当秒除以 60。
推荐安全写法：
- 总秒数 =
Math.floor(remainingMs / 1000)，再分别取hours = Math.floor(totalSec / 3600)、minutes = Math.floor((totalSec % 3600) / 60)、seconds = totalSec % 60 - 补零统一用
(num).toString().padStart(2, '0')，或降级为num - 避免使用
toTimeString()或toLocaleTimeString()，它们受本地时区和格式影响，不可控
页面卸载或切换标签页时倒计时还在跑？
用户切走再回来，发现倒计时明显滞后甚至直接归零，是因为定时器没暂停。浏览器对后台标签页会节流 setTimeout/setInterval，但不会自动停掉——你得自己响应可见性变化。
实操建议：
- 监听
document.visibilityState变化，在visibilityState === 'hidden'时clearTimeout，并记录暂停时刻 - 切回时（
'visible'），用当前时间与暂停时刻差值修正剩余毫秒，再继续setTimeout - 也可改用
requestIdleCallback配合时间戳校验，但复杂度上升，多数场景用 visibility API 就够了
倒计时看着简单，真正稳定运行要同时扛住时间精度、生命周期、用户行为三重干扰。最常被忽略的是：不校验 remainingMs 就清定时器，以及切页后不暂停导致的逻辑漂移。