倒计时无法用原生html实现暂停/恢复/跳转，必须用javascript手动管理定时器；推荐setinterval而非requestanimationframe；页面后台时需服务端托管或localstorage+visibilitychange方案。
倒计时能暂停/恢复/跳转吗？原生 HTML 不行，得靠 JavaScript
HTML 本身没有倒计时组件，更不支持暂停、重置或动态修改剩余时间。<meter></meter> 或 <progress></progress> 只是视觉展示，和时间逻辑完全无关。真正的时间控制必须用 JavaScript 手动管理定时器和状态。
常见错误是把倒计时写成一次性 setTimeout，结果无法干预；或者用 setInterval 但没保存 timer ID，导致 clearInterval 失效，暂停功能直接瘫痪。
- 必须用
let timerId = null显式保存定时器引用 - 每次暂停前要先
clearInterval(timerId)，恢复时重新setInterval - 跳转（如设为剩余 60 秒）不能只改显示值，必须同步重置内部计数变量和 timer
setInterval 和 requestAnimationFrame 哪个更适合倒计时？
绝大多数场景下坚持用 setInterval，别被“动画帧更精准”误导。倒计时本质是时间刻度对齐（比如每秒更新），不是视觉帧率敏感任务。
requestAnimationFrame 的问题是：它不保证 16ms 执行一次，实际间隔受页面可见性、CPU 负载、后台标签页节流影响极大。用户切到其他 tab 后再回来，倒计时可能已跳过好几秒——这在支付、答题类场景是严重 bug。
-
setInterval(fn, 1000)虽有轻微漂移（V8 引擎延迟约 ±5ms），但稳定可预期 - 若需更高精度（如毫秒级倒计时），应基于
Date.now()计算已流逝时间，而非依赖 setInterval 次数 - 务必在每次回调开头调用
Date.now()获取真实当前时间，避免累计误差
怎么让倒计时在页面卸载后继续运行？浏览器限制很硬
标准网页中，页面进入后台或关闭标签页时，setInterval 和 setTimeout 会被浏览器大幅降频甚至暂停（Chrome 通常限为 1s 以上间隔）。这意味着你无法靠前端代码实现“真后台倒计时”。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
可行解只有两个方向：
- 服务端托管：把结束时间存到后端，前端只负责轮询或用 WebSocket 接收到期通知。适合登录态明确、需强一致性的场景（如订单超时）
- 利用
localStorage+ 页面激活检测：记录开始时间和总时长，每次页面visibilitychange或focus时，用Date.now()算出真实剩余秒数并刷新 UI。注意要处理跨设备、时钟不同步问题
别试图用 Service Worker 拦截倒计时——它无法访问页面 DOM，也不能直接触发 UI 更新，只能发通知，且 Android Chrome 对 SW 后台存活极不友好。
移动端键盘弹出导致倒计时卡顿？布局重排是元凶
很多 H5 活动页在 iOS Safari 上，软键盘弹出会触发整个视口缩放或滚动，引发 layout thrashing，间接拖慢 JS 执行，造成倒计时跳秒或延迟更新。
关键不是定时器本身，而是更新 DOM 的方式太重：
- 避免每次更新都操作
innerHTML或频繁读取offsetHeight等触发重排的属性 - 用
textContent替代innerHTML更新纯文本倒计时数字 - 把倒计时容器设为
position: absolute或transform: translateZ(0)，减少重排影响范围 - iOS 上可监听
keyboardWillShow（通过 WebKit 事件或 resize hack）提前隐藏非必要元素
最隐蔽的坑是：这个卡顿只在真机出现，DevTools 里完全复现不了。上线前务必用 iOS 真机连 Safari Web Inspector 测试。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
