浏览器卡顿时定时器延迟或停止是因主线程阻塞及非活跃页面节流所致；应通过Performance面板定位阻塞、用requestAnimationFrame替代重绘、拆分耗时任务、清理未清除定时器，并在后台时用visibilitychange事件控制，关键场景依赖时间差补偿或Web Worker保障精度。
浏览器页面卡顿时，定时器（setTimeout/setInterval）常出现延迟、跳过甚至完全停止触发，这不是代码写错了，而是浏览器主动限制的结果。核心原因是：JS运行在单线程中，当主线程被高负载任务（如长渲染、大量DOM操作、内存紧张）阻塞时，定时器回调无法及时入队执行；更关键的是，现代浏览器（Chrome 57+、Android WebView、iOS Safari）对非活跃页面实施了严格的节流策略——哪怕页面没切后台，只是滚动卡住、JS执行过久或系统资源吃紧，计时逻辑也会被挂起。
检查并释放主线程压力
卡顿往往源于主线程长期占用，导致定时器回调“排队失败”：
- 用浏览器开发者工具（F12 → Performance 面板）录制页面操作，查看是否存在长时间的“Scripting”或“Rendering”阻塞块
- 避免在定时器回调里做重绘操作（如频繁修改
innerHTML、触发强制同步布局），改用requestAnimationFrame批量更新 - 将耗时计算（如数据解析、加密）移出定时器，或拆分为微任务（
Promise.then）分片执行 - 确认没有未清除的定时器叠加：每次启动新定时器前，先
clearInterval(timerId)，尤其在组件销毁、页面跳转前
应对页面非活跃状态的节流
当页面被最小化、切到后台、锁屏或WebView休眠时，浏览器会强制拉长定时器间隔（Chrome 后台最小间隔为 1000ms），甚至暂停 requestAnimationFrame 和 CSS 动画：
- 监听
visibilitychange事件，在document.hidden === true时主动clearInterval，并在恢复可见时重置起始时间并重启 - 不依赖“绝对时间间隔”，改用相对时间差补偿：记录上一次触发的
performance.now()，每次执行时计算真实经过毫秒数，再决定是否触发业务逻辑 - 对金币结算、视频进度等强时效场景，后端应配合校验客户端上报的时间戳，而非仅信任前端定时器
绕过主线程限制的进阶方案
当必须保证计时精度且无法规避卡顿/后台限制时，可考虑脱离主线程：
- 使用 Web Worker 运行独立计时逻辑：Worker 不受页面可见性影响，能稳定每秒触发；通过
postMessage与主线程通信同步状态（注意它不能直接操作 DOM） - 对倒计时类需求，优先封装
requestAnimationFrame+ 时间差补偿的自定义animationInterval，比setInterval更适应浏览器重绘节奏 - 移动端 WebView 场景（如悟空浏览器），若反复卡死，可尝试启用无痕模式或禁用广告过滤/防沉迷类插件——它们常劫持
setTimeout全局行为
本质上，这不是 bug，而是浏览器在性能、功耗与功能间做的权衡。处理的关键不是“让定时器强行跑起来”，而是适配它的行为规律：主动管理生命周期、用时间差代替固定间隔、把不可靠的交给可靠的（比如后端校验或 Worker）。
