setTimeout仅执行一次，setInterval重复执行；两者均基于事件循环异步调度、不保证精确延迟，需用clearTimeout/clearInterval清理，且避免字符串传参或立即调用函数。
JavaScript定时器（setTimeout 和 setInterval）在不同JavaScript引擎中并非统一实现，其底层行为差异主要源于事件循环调度机制、时间精度控制、任务队列优先级以及与宿主环境（如浏览器或Node.js）的协同方式。这些差异直接影响定时器的触发时机、最小延迟、节流表现和内存行为。
V8引擎（Chrome / Edge / Node.js）：基于消息循环与延迟补偿
V8本身不直接管理定时器，而是将定时器注册委托给宿主环境的事件循环（如libuv在Node.js中，或Chromium的MessageLoop在浏览器中）。V8仅提供JS层API接口，实际调度由底层系统完成。关键特点包括：
- 最小延迟强制为1ms：即使传入0，浏览器环境下仍至少延迟1ms（HTML规范要求），Node.js中可接近0但受libuv线程池及系统调度影响；
- 延迟补偿机制：若主线程长时间阻塞，后续定时器会“追赶”——多个到期定时器可能被压缩到同一轮事件循环中连续执行（但不会真正并行）；
-
空闲回调优化：Chrome支持
requestIdleCallback，与定时器独立调度，但共享同一事件循环，优先级更低。
SpiderMonkey（Firefox）：基于Pump与高精度时钟
Firefox使用Gecko的事件循环（称为“Pump”），定时器由nsITimer系统管理，底层依赖操作系统高精度时钟（如clock_gettime(CLOCK_MONOTONIC)）。其差异体现在：
- 更严格的延迟保证：在低负载下，1ms定时器的实际偏差通常小于V8（尤其在Linux/macOS上）；
- 无自动追赶行为：若主线程阻塞，错过的时间不会被补偿，后续定时器按原始间隔继续，即“跳过”已错失的触发点；
-
后台标签页节流更强：非活跃标签页中，
setTimeout最小间隔被限制为1000ms（可配置），且不累积未触发任务。
JavaScriptCore（Safari）：基于RunLoop与WebCore集成
JSC深度集成于WebKit的RunLoop机制，定时器由WebCore::Timer类封装，与渲染、网络等任务共用同一调度器。典型特征有：
立即学习“Java免费学习笔记（深入）”；
-
渲染帧对齐倾向：在页面可见且有动画需求时，定时器可能被自动对齐到
requestAnimationFrame周期附近，以减少布局抖动； - 动态精度调整：iOS/iPadOS上为省电会主动降低后台页面定时器精度（如延长至数秒），且不暴露具体策略；
- 无独立微任务队列介入：定时器回调始终进入宏任务队列，不会因Promise链意外提升优先级（与某些V8早期版本行为不同）。
跨引擎共性与可移植陷阱
尽管底层不同，所有引擎都遵守ECMAScript规范中关于“定时器是宏任务”的语义。但开发者易忽略的兼容性问题包括：
- 0ms不等于立即执行：所有引擎都会将其提升至最小合法延迟（通常1ms），且需等待当前调用栈清空；
- clearTimeout/setTimeout非原子操作：在极端高负载下，V8与JSC存在极小概率的竞态（如刚创建即清除却仍触发），应避免依赖该边界行为；
- 嵌套setTimeout比setInterval更可控：因后者在引擎内部可能累积误差，而前者每次重置计时起点，跨引擎一致性更高。
不复杂但容易忽略：定时器不是精确时钟，而是事件循环的调度提示。真正决定执行时机的，是宿主环境如何把JS定时请求翻译成系统级timerfd、mach_absolute_time或QueryPerformanceCounter调用——这才是差异真正的源头。
