倒计时结束需手动判断并执行回调，应使用时间戳计算剩余时间（如Math.max(0, Math.ceil((deadline - Date.now()) / 1000))），在remaining === 0时触发自定义操作；结合Page Visibility API，在visibilitychange时校验是否超时，确保准确性。
怎么让倒计时结束时触发自定义操作
倒计时结束不自动弹窗、不发请求、不切换状态，是因为你没写回调逻辑——setInterval 只管“数数”，不管“数完干啥”。真正的结束提示必须手动判断并执行，没有内置的 onEnd 钩子。
常见错误现象：clearInterval 后页面静默，用户根本不知道结束了；或者把提示逻辑写在定时器外部，导致只执行一次或完全不执行。
- 用
setInterval每秒检查剩余时间，当remaining 时立即调用你的处理函数（比如 <code>showAlert()或submitForm()） - 务必在触发回调后立刻
clearInterval，否则可能重复执行（尤其在慢设备或卡顿页面中） - 别依赖
setTimeout精确到毫秒级结束——它受事件循环影响，实际延迟可能偏差几百毫秒
为什么 Date.now() 比递减变量更可靠
用 let seconds = 60; setInterval(() => seconds--, 1000) 看似简单，但一旦页面切到后台、系统休眠或 JS 执行被阻塞，seconds 就会严重失准，甚至倒计时“跳过”结束点。
使用时间戳计算才是生产环境通用做法：每次检查都拿当前时间跟目标截止时间比对，不受中间执行波动影响。
立即学习“前端免费学习笔记（深入）”；
- 初始化时存一个绝对截止时间：
const deadline = Date.now() + 60 * 1000 - 定时器里算差值：
const remaining = Math.max(0, Math.ceil((deadline - Date.now()) / 1000)) - 当
remaining === 0，说明真实时间已到，此时触发回调最可信
DOM 更新卡顿？别在 setInterval 里直接改 innerHTML
高频更新倒计时数字（如每秒一次）本身没问题，但如果你在回调里同时做动画、AJAX 请求或批量 DOM 插入，就容易引发重排重绘，导致倒计时跳秒甚至卡死。
性能影响明显：低端安卓机上，连续操作 innerHTML 可能让倒计时从“1s/次”退化成“3s/次”，最终错过结束判断。
- 只更新必要元素，例如仅修改
document.getElementById('countdown').textContent - 避免在倒计时逻辑中调用
getBoundingClientRect()或读取offsetHeight等触发回流的属性 - 如果必须联动其他操作（如禁用按钮），放在结束回调里一次性处理，不要塞进每秒执行的定时器主体
移动端切后台后倒计时不准怎么办
iOS Safari 和部分安卓浏览器在标签页不可见时会大幅降低 setInterval 频率（甚至暂停），导致倒计时“睡过头”，醒来才发现早就该结束了。
这不是 bug，是浏览器省电策略。靠延长间隔或轮询无法根治，得换思路：用可见性 API 补偿。
- 监听
document.visibilityState，页面重新可见时立刻重算剩余时间 - 结合
Page Visibility API：在visibilitychange事件中调用一次结束检查逻辑 - 别依赖“刚好第 N 次触发”，始终以
Date.now()和deadline的差值为唯一依据
复杂点在于：你得同时处理定时器节奏、页面生命周期、用户交互三者的耦合。最容易被忽略的是——没在页面重获焦点时主动校验是否已超时，结果用户切回来还看到 “3…2…1…” 假象。
