setTimeout的实际延迟不是随机误差，而是由主线程占用、最小延迟钳制和微任务队列清空三类确定性因素共同导致的系统性偏移，无法用概率分布建模。
setTimeout 的延迟参数和实际延迟之间，不存在稳定、可预测的概率分布。它不是随机误差，而是由确定性机制叠加环境变量共同导致的系统性偏移。
实际延迟主要受三类确定性因素主导
浏览器不会“掷骰子”决定延迟多久，而是严格遵循事件循环规则，再叠加运行时约束：
-
主线程占用时长：同步代码执行时间直接叠加到定时器上。例如设了
setTimeout(fn, 10)，但前面有耗时 80ms 的计算，那 fn 至少在 90ms 后才可能执行——这不是概率问题，是必然结果。 - 最小延迟钳制（clamping）：Chrome/Firefox 对非嵌套调用强制 ≥4ms；嵌套 5 层以上明确为 ≥4ms；后台标签页统一节流至 ≥1000ms。这些是硬性下限，不是统计均值。
- 微任务队列清空延迟：即使主线程空闲，setTimeout 回调也必须等当前宏任务结束 + 所有 pending 微任务（Promise.then、queueMicrotask）执行完毕才能触发。这部分耗时取决于代码逻辑，而非随机波动。
为什么不能建模为概率分布
所谓“概率分布”隐含独立同分布（i.i.d.）假设，但 setTimeout 实际延迟高度依赖上下文：
- 同一页面中连续两次
setTimeout(fn, 100)，若第一次执行前刚完成一个 200ms 渲染，第二次前只做了 2ms 计算，两次延迟可能相差近 200ms——这不是方差大，而是条件不同。 - 后台标签页下，所有 setTimeout 延迟都会被拉到 ≥1000ms，此时“分布”退化为单点（或极窄区间），失去统计意义。
- 设备负载、电源模式、是否启用开发者工具等外部状态，会动态改变调度行为，无法固定采样条件。
更实用的替代视角：偏差来源分类与可观测性
比起拟合分布，关注以下三类可测量/可干预的偏差更有效：
-
基础偏移：用
performance.now()在回调内记录真实触发时间，减去设定延迟与起始时间，得到单次偏差值。 - 累积漂移：在倒计时类场景中，每次执行后重新计算剩余时间（而非累加 fixed delay），可消除线性漂移。
-
节流干扰：检测
document.hidden状态，后台时主动暂停或切换为 visibilitychange 触发逻辑，避免千毫秒级突变。
真正需要时间敏感逻辑时，应放弃对 setTimeout 单次精度的依赖，转而用 performance.now() 做运行时校准，或使用 requestAnimationFrame 对齐渲染帧节奏。它不是一个不准的钟，而是一张必须排队领号的预约单——关键不在号牌数字，而在你前面有多少人在窗口办事。
