JavaScript定时器在不同浏览器中存在执行时机、精度、节流策略及参数传递差异：最小延迟不一致（Chrome/Firefox≈1ms，Safari 4–10ms，Android WebView≥16ms），后台标签页节流策略各异（Chrome/Firefox/Edge拉长至1000ms+，旧Safari不主动节流），setInterval易跳帧且错误不中断，推荐用requestAnimationFrame替代动画类任务，或采用时间锚点校准轮询。
JavaScript 定时器（setTimeout 和 setInterval）在不同浏览器中并非“一视同仁”，它们的执行时机、精度、节流策略甚至参数传递方式都存在实质性差异。这不是代码写错了，而是浏览器底层实现机制不同导致的客观行为偏差。
最小延迟与高频调度不一致
各浏览器对“零延迟”或小间隔（如 1ms–10ms）的处理差异明显：
- Chrome/Firefox 现代版本通常将
setTimeout(fn, 0)实际延迟控制在 ≈1ms（嵌套调用可更低），但 Safari（尤其 iOS 15 前）会强制提升至 4–10ms；部分 Android WebView 或小程序环境甚至限制为 ≥16ms（对齐 60fps 刷新率） - IE9–11 对高频定时器敏感，短时间内密集注册（如每 1ms 一个）易被合并、跳过或延迟执行，且无明确提示
- 传参兼容性也有坑：同一段
setTimeout(f, 500, 'a', 'b')在 IE 中可能收不到参数，Firefox 可能多出一个负数时间戳参数，Opera 则按预期传两个
页面失焦时的节流策略各异
当用户切换标签页或最小化窗口，浏览器为节省资源会对定时器降频，但策略不统一：
- Chrome v70+、Firefox v59+、Edge 80+ 默认将后台标签页中的
setInterval间隔拉长至 1000ms 以上，setTimeout同样大幅延迟 - 旧版 Safari（如 10–12）和部分鸿蒙轻应用 WebView 不主动节流，或节流逻辑不透明，导致后台仍频繁触发，耗电/卡顿
-
requestAnimationFrame在所有主流浏览器中行为一致：页面不可见时自动暂停，恢复可见时同步刷新节奏，天然规避此问题
时间漂移与执行跳帧难以避免
定时器不是钟表，而是事件循环中的宏任务调度器，长期运行必然产生偏移：
立即学习“Java免费学习笔记（深入）”；
-
setInterval每次投递基于“上一次入队时间”，而非“上一次执行完成时间”。若某次回调耗时 200ms，而间隔设为 100ms，则后续三次本该触发的调用会被跳过，直接执行第 4 次——造成跳帧 - 连续使用
setTimeout模拟循环时，各浏览器对回调调度的精度不同，运行 10 分钟后，实际触发次数可能比理论值少 10–30 次，倒计时显示会明显慢于服务端时间 - 错误不中断是隐蔽风险：
setInterval内部抛错不会停止定时器，错误仅冒泡到window.onerror，容易掩盖 DOM 已销毁却仍在操作等致命问题
替代与补偿方案更可靠
与其纠结兼容性，不如按场景选更稳健的方案：
- 视觉更新类（动画、滚动、UI 渲染）优先用
requestAnimationFrame，它由浏览器统一调度，跨平台行为高度一致 - 需固定间隔的业务（如心跳、轮询），避免裸用
setInterval，改用时间锚点校准：记录起始时间，每次回调中计算已过时长，动态调整下次延迟，抵消累积误差 - 对精度要求极高或需后台持续运行的任务（如音视频同步），考虑 Web Workers 隔离主线程，或结合
performance.now()手动测算真实耗时 - 旧环境兜底可用 Polyfill，例如封装带 fallback 的 ticker 函数，内部自动检测是否支持
rAF，不支持则退回到修正后的setTimeout
