settimeout的延迟参数仅表示回调入队的最早时间，不包含执行耗时；其真实含义是“最小等待时长”，实际执行时刻取决于主线程空闲状态。

不包含。setTimeout 的延迟参数只控制回调函数被放入任务队列的最早时间，和回调函数本身的执行耗时完全无关。

延迟参数的真实含义是“最小等待时长”

delay 毫秒数是从调用 setTimeout 那一刻起，到回调函数被推入宏任务队列的时间下限。它不计算回调函数运行花了多久，也不保证回调一定在 delay 毫秒后开始执行——实际执行时刻取决于主线程是否空闲。

• 如果主线程正执行一个 200ms 的同步任务，而你设了 setTimeout(fn, 100)，fn 会在 200ms 后才被放进队列，再等主线程空闲才能执行
• 回调函数一旦开始执行，其内部耗时（比如遍历万级数组、渲染复杂 DOM）会延长整体完成时间，但这个时间不计入 delay
• 浏览器对后台标签页或嵌套过深的定时器会主动节流（如最小间隔拉长到 1000ms），这也会使实际排队起点晚于预期

性能指标要分三层看

评估 setTimeout 行为不能只盯 delay 参数，需拆解为三个独立阶段：

宝塔Linux面板11.3.0

宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。

下载

• 调度延迟（Scheduling Delay）：从 setTimeout 调用到回调入队的时间差。受事件循环当前状态影响，可能远大于 delay
• 排队等待（Queue Wait）：回调在宏任务队列中等待主线程释放的时间。若前序任务长，这一段可能达数百毫秒
• 执行耗时（Execution Time）：回调函数自身运行所花时间。它不影响下一次 setTimeout 的计时起点，但会影响后续任务响应

如何验证这三段耗时？

可以用 performance.now() 在关键节点打点：

• 调用 setTimeout 前记 time1
• 回调函数第一行记 time2（≈ 入队完成+开始执行时刻）
• 回调函数最后一行记 time3
• 那么：调度延迟 ≈ time2 - time1，排队等待 ≈ time2 - (time1 + delay)，执行耗时 ≈ time3 - time2

影响精度的常见干扰项

这些因素会让 delay 参数显得“不准”，但其实它始终按规范工作：

• 页面处于后台标签页时，浏览器可能将定时器最小间隔提升至 1000ms，导致所有 setTimeout 实际延迟至少 1s
• 连续多次 setTimeout(…, 0) 不会立即执行，而是全部排队，按调用顺序依次触发
• 高 CPU 占用或内存紧张时，JS 引擎可能降低定时器轮询频率，进一步放大偏差