settimeout 是“延后调度”而非“延时执行”，其回调被推入宏任务队列，需等同步代码和所有微任务执行完毕后才执行，受事件循环负载影响，存在延迟不精确问题。
setTimeout 不是“延时执行”，而是“延后调度”——它把回调函数放进宏任务队列，等当前所有同步代码和微任务跑完，主线程空闲时才轮到它执行。
setTimeout 的真实执行流程
它不占用主线程，也不创建新线程，而是在浏览器或 Node.js 的 Web API 环境中启动一个计时器。计时器到期后，并不会立刻调用回调，而是把该回调推入宏任务队列（macrotask queue）。只有当执行栈清空、所有微任务（如 Promise.then）执行完毕后，事件循环才会从宏任务队列中取出第一个任务执行。
- 同步代码永远优先于 setTimeout 回调执行
- 即使 delay 设为 0，回调也一定排在当前同步任务和所有微任务之后
- 多个 setTimeout 的执行顺序取决于它们进入宏任务队列的先后，不是严格按设定时间排序（受事件循环负载影响）
为什么 setTimeout 看起来“不准”？
它的延迟只是最小等待时间，不是精确触发时刻。如果主线程正忙（比如运行长循环、大量计算或阻塞操作），计时器到期后仍需排队等待。例如：
- 死循环会彻底阻塞 setTimeout：while(true){} 运行期间，宏任务队列无法被消费，哪怕 10 秒后到期的 setTimeout 也不会执行
- 高负载下延迟放大：若页面正在渲染大量 DOM 或执行密集脚本，setTimeout 回调可能比设定时间晚数百毫秒才运行
- 系统节流：后台标签页中，浏览器常将 setTimeout 最小间隔限制为 1000ms，防止资源滥用
setTimeout 与 Promise.then 的执行顺序
这是理解事件循环的关键分水岭。Promise.then 属于微任务（microtask），而 setTimeout 是宏任务（macrotask）。微任务总在当前任务结束、下一轮宏任务开始前全部清空。
- 一个同步任务结束后，先执行所有已加入的 Promise.then、queueMicrotask 回调
- 再从宏任务队列取下一个任务（可能是 setTimeout、setInterval、I/O 回调等）
- 因此：
console.log(1); Promise.resolve().then(() => console.log(2)); setTimeout(() => console.log(3), 0); console.log(4);输出顺序是 1 → 4 → 2 → 3
常见误用与规避建议
开发者常把它当作“sleep”或“让出线程”，但 JavaScript 没有真正的 sleep，也没有线程让渡概念。错误用法会引发 UI 卡顿或逻辑错乱。
- 别用 while 循环模拟延迟——它阻塞主线程，UI 冻结，setTimeout 也无法触发
- 避免嵌套多层 setTimeout 控制流程——改用 Promise 链或 async/await 更清晰可靠
- 需要精确节奏（如动画）时，优先考虑 requestAnimationFrame；定时轮询用 setInterval 要配合 clearTimeout 防泄漏
- 清理很重要：setTimeout 返回 timer ID，务必在不需要时 clearTimeout()，尤其在组件卸载或请求取消场景下
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
