文档/教程前端【免费下载链接】en.javascript.infoModern JavaScript Tutorial项目地址https://gitcode.com/gh_mirrors/en/en.javascript.info点击查看免费下载导读本文基于 Modern JavaScript Tutorial现代 JavaScript 教程中的一道经典练习4-settimeout-result/task.md及其标准解答solution.md深入剖析setTimeout的回调执行时机。读完本文你将彻底理解定时器回调必然在当前同步代码全部执行完之后才运行这一事件循环核心规律掌握零延迟定时器、宏任务/微任务的区别并学会利用该特性拆分 CPU 密集型任务、避免界面卡顿的实战方案。练习setTimeout 会弹出什么值在 JavaScript 进阶函数章节的调度Scheduling主题下教程设置了这样一道练习题task.mdlet i 0; setTimeout(() alert(i), 100); // ? // 假设执行这段函数所需时间 100ms for(let j 0; j 100000000; j) { i; }题目问了两个问题被调度的函数会在什么时候运行循环之后After the loop循环之前Before the loop循环刚开始时In the beginning of the loopalert最终会弹出什么值正确答案循环之后弹出 100000000标准答案solution.md给出的结论非常简洁而深刻AnysetTimeoutwill run only after the current code has finished.任何一个setTimeout的回调只会在当前代码执行完毕之后才会运行。因此被调度的函数在循环之后运行选项 1alert弹窗显示的是循环结束后的最终值100000000i从 0 自增了 1 亿次而不是循环过程中的某个中间值。完整验证代码let i 0; setTimeout(() alert(i), 100); // 100000000 // 假设执行这段函数所需时间 100ms for(let j 0; j 100000000; j) { i; }即使setTimeout指定的延迟只有 100ms而循环体理论上需要超过 100ms 才能跑完回调依然不会插队到循环中间执行——它必须排队等待当前正在执行的这段同步代码彻底结束。背后原理事件循环与宏任务队列要真正理解这个结论需要回到浏览器以及 Node.js的事件循环Event Loop模型这正是教程在 event-loop 章节 中系统讲解的内容。事件循环的本质是一个无限循环只要有任务task就按先来先服务的顺序执行它们从最老的任务开始没有任务时就休眠等待新任务出现后回到第 1 步。setTimeout到期的回调、用户鼠标事件、网络请求回调、外部脚本加载等都属于宏任务macrotask会被放入宏任务队列排队。浏览器引擎同一时刻只能执行一个任务当引擎正忙于执行当前这段脚本包含那个 1 亿次的 for 循环时即使定时器早已到期它的回调也只会被入队要等当前任务执行完、引擎空闲下来才会被取出执行。这正是本题的核心考点定时器的delay只是最早执行时间不是保证执行时间。回调永远不会打断正在运行的同步代码。零延迟 setTimeout 也不是立即执行同样的规律在零延迟场景下体现得淋漓尽致。教程主文article.md专门用一节讲解setTimeout(() alert(World)); alert(Hello);第一行代码把调用放进 0ms 之后的日历但调度器只有在当前脚本执行完毕之后才会去查看日历。因此输出顺序一定是先Hello、后World。所以setTimeout(func, 0)等价于setTimeout(func)的真实语义是尽快执行但必须在当前脚本执行完之后。它只是把函数调度到当前代码之后、渲染和后续事件处理之前运行。定时器回调不会读取到循环中途的值理解了执行时机第二个问题的答案也就顺理成章回调运行时循环早已结束它读取到的i必然是最终值100000000。这还引出一个容易踩坑的经典场景如果在循环体内用setTimeout或闭包捕获循环变量捕获到的是循环结束后的最终值而不是每次迭代时的中间值。本题正是这一现象的极端示范——回调根本不会在循环期间运行自然拿不到任何中间值。宏任务与微任务谁先执行为了更精确地理解当前代码执行完之后究竟先跑什么还需要区分两类异步任务。教程在 microtask-queue 章节 中说明Promise 的.then/.catch/.finally处理器会进入内部的微任务队列microtask queue而setTimeout回调属于宏任务队列。事件循环处理完一个宏任务后会先把微任务队列清空再去处理下一个宏任务或执行渲染。看这个对比setTimeout(() alert(timeout)); // 宏任务 Promise.resolve() .then(() alert(promise)); // 微任务 alert(code); // 同步代码输出顺序为code→promise→timeout。也就是说同步代码最先执行code微任务在当前代码结束后立即执行promise宏任务setTimeout回调排在微任务之后timeout。回到本题即使把setTimeout换成 Promise结论依然成立——回调/处理器同样只能等当前同步循环跑完。区别只在于 Promise 处理器微任务会比定时器回调宏任务更早从队列中被取出执行。实战启示利用 setTimeout 拆分 CPU 密集型任务理解了回调只会在当前代码结束后运行一个非常有价值的实战应用就是拆分 CPU 密集型任务。教程 event-loop 章节的 Use-case 1 给出了完整方案。假设有一个从 1 数到 10 亿的重型计算let i 0; let start Date.now(); function count() { for (let j 0; j 1e9; j) { i; } alert(Done in (Date.now() - start) ms); } count();这段代码会让浏览器引擎长时间挂起期间无法处理任何用户点击事件甚至可能触发脚本运行时间过长的警告。原因正是事件循环的另一个细节引擎执行一个任务期间不会发生渲染也不会处理其他任务。解决办法是利用零延迟setTimeout把大任务切分成小块每完成一小块就把控制权交还给事件循环let i 0; let start Date.now(); function count() { // 只做一小部分工作 (*) do { i; } while (i % 1e6 ! 0); if (i 1e9) { alert(Done in (Date.now() - start) ms); } else { setTimeout(count); // 重新调度下一次执行 (**) } } count();执行流程是第一次运行数到 100 万第二次数到 200 万……每两次执行之间都会回到事件循环此时用户的点击、鼠标移动等事件得以插入处理浏览器界面保持可交互。教程指出拆分后的总耗时与不拆分相差无几却换来了流畅的 UI 体验。更进一步把调度语句移到count()开头还能显著提速因为浏览器对多层嵌套定时器有至少 4ms 的最小延迟限制详见下文越早调度后续每一轮就越早开始。补充setInterval 与嵌套 setTimeout 的精度差异与本题同章节的姊妹练习 1-output-numbers-100ms 展示了两种定时输出的写法setInterval版和嵌套setTimeout版。主文 article.md 进一步对比了两者的时序精度setInterval以固定间隔触发回调但回调自身的执行时间会吃掉一部分间隔导致两次调用之间的实际间隔小于设定值若回调执行时间超过间隔引擎会在回调结束后立即再次调用极端情况下变成无间隔连续调用。嵌套setTimeout下一次调用在上一次回调结束之后才被调度因此两次执行之间的间隔是固定的如稳定的 100ms。示意图如下setInterval中回调的执行时间会压缩实际间隔嵌套setTimeout保证两次执行之间间隔固定这也解释了本文主题为何重要无论是setInterval还是setTimeout回调的运行时刻都受事件循环调度约束绝不会打断正在执行的同步代码也不会精确保证延迟。浏览器对定时器的 4ms 最小延迟限制主文还强调了一个浏览器特有的细节article.mdHTML Living Standard 规定嵌套 5 层以上的定时器强制最小间隔为 4ms。零延迟自调度测试的实际输出类似1,1,1,1,9,15,20,24,30,35,40,45,50,55,59,64,70,75,80,85,90,95,100前 4 次几乎立即执行之后便出现 4ms 的强制延迟。这一限制是历史遗留大量旧脚本依赖它仅存在于浏览器Node.js 服务端没有该限制可使用setImmediate等替代方案。此外CPU 过载、标签页在后台、笔记本节能模式等都可能把最小定时器分辨率拉高到 300ms 甚至 1000ms——所有调度方法都不保证精确的延迟。总结通过这道练习我们掌握了以下核心知识setTimeout回调永远在当前同步代码执行完毕后运行——即使延迟已到、即使延迟为 0回调也只能排队等待solution.md因此在重型循环中调度的回调读取到的必然是循环结束后的最终变量值本例为100000000其底层原因是事件循环的宏任务队列模型引擎同一时刻只执行一个任务定时器回调属于宏任务必须等当前任务完成event-loop 章节宏任务与微任务有明确的优先级当前代码结束后先清空微任务队列Promise 处理器再执行下一个宏任务microtask-queue 章节这一规律可以反过来利用用零延迟setTimeout拆分 CPU 密集型任务把执行权周期性交还给事件循环从而保持页面响应、支持进度显示调度方法不保证精确延迟回调执行时间、4ms 嵌套限制、后台标签页与节能模式都会影响真实触发时机。下次再遇到定时器里的变量值为什么不对页面为什么卡死这类问题先想想事件循环回调永远在排队当前代码不结束它绝不运行。赞分享文档/教程前端【免费下载链接】en.javascript.infoModern JavaScript Tutorial项目地址https://gitcode.com/gh_mirrors/en/en.javascript.info点击查看免费下载相关推荐Metro运行时系统如何在设备上执行打包后的代码Metro运行时系统如何在设备上执行打包后的代码 Metro是React Native的JavaScript打包器负责将开发者的源代码转换为可在移动设构建工具移动开发CLIPowerToys隐藏神器清单Awake、Screen Ruler、Quick Accent等8个被低估的小工具让你快人一步PowerToys隐藏神器清单Awake、Screen Ruler、Quick Accent等8个被低估的小工具让你快人一步 PowerToys 是微软官方出桌面应用开发工具Darklang运行时代码执行环境构建Darklang运行时代码执行环境构建 概述 Darklang是一个革命性的编程语言和开发平台它将语言、编辑器和基础设施无缝集成让后端和CLI应用开发变得上一篇UE4SS终极指南解锁虚幻引擎游戏的完整修改方案下一篇终极指南30分钟打造专属精简Windows 11系统让老旧电脑焕发新生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/5 6:44:40 · 阅读 1.2k JavaScript setTimeout 执行时机详解：为什么回调只会在当前代码执行完毕后运行
文档/教程前端【免费下载链接】en.javascript.infoModern JavaScript Tutorial项目地址https://gitcode.com/gh_mirrors/en/en.javascript.info点击查看免费下载导读本文基于 Modern JavaScript Tutorial现代 JavaScript 教程中的一道经典练习4-settimeout-result/task.md及其标准解答solution.md深入剖析setTimeout的回调执行时机。读完本文你将彻底理解定时器回调必然在当前同步代码全部执行完之后才运行这一事件循环核心规律掌握零延迟定时器、宏任务/微任务的区别并学会利用该特性拆分 CPU 密集型任务、避免界面卡顿的实战方案。练习setTimeout 会弹出什么值在 JavaScript 进阶函数章节的调度Scheduling主题下教程设置了这样一道练习题task.mdlet i 0; setTimeout(() alert(i), 100); // ? // 假设执行这段函数所需时间 100ms for(let j 0; j 100000000; j) { i; }题目问了两个问题被调度的函数会在什么时候运行循环之后After the loop循环之前Before the loop循环刚开始时In the beginning of the loopalert最终会弹出什么值正确答案循环之后弹出 100000000标准答案solution.md给出的结论非常简洁而深刻AnysetTimeoutwill run only after the current code has finished.任何一个setTimeout的回调只会在当前代码执行完毕之后才会运行。因此被调度的函数在循环之后运行选项 1alert弹窗显示的是循环结束后的最终值100000000i从 0 自增了 1 亿次而不是循环过程中的某个中间值。完整验证代码let i 0; setTimeout(() alert(i), 100); // 100000000 // 假设执行这段函数所需时间 100ms for(let j 0; j 100000000; j) { i; }即使setTimeout指定的延迟只有 100ms而循环体理论上需要超过 100ms 才能跑完回调依然不会插队到循环中间执行——它必须排队等待当前正在执行的这段同步代码彻底结束。背后原理事件循环与宏任务队列要真正理解这个结论需要回到浏览器以及 Node.js的事件循环Event Loop模型这正是教程在 event-loop 章节 中系统讲解的内容。事件循环的本质是一个无限循环只要有任务task就按先来先服务的顺序执行它们从最老的任务开始没有任务时就休眠等待新任务出现后回到第 1 步。setTimeout到期的回调、用户鼠标事件、网络请求回调、外部脚本加载等都属于宏任务macrotask会被放入宏任务队列排队。浏览器引擎同一时刻只能执行一个任务当引擎正忙于执行当前这段脚本包含那个 1 亿次的 for 循环时即使定时器早已到期它的回调也只会被入队要等当前任务执行完、引擎空闲下来才会被取出执行。这正是本题的核心考点定时器的delay只是最早执行时间不是保证执行时间。回调永远不会打断正在运行的同步代码。零延迟 setTimeout 也不是立即执行同样的规律在零延迟场景下体现得淋漓尽致。教程主文article.md专门用一节讲解setTimeout(() alert(World)); alert(Hello);第一行代码把调用放进 0ms 之后的日历但调度器只有在当前脚本执行完毕之后才会去查看日历。因此输出顺序一定是先Hello、后World。所以setTimeout(func, 0)等价于setTimeout(func)的真实语义是尽快执行但必须在当前脚本执行完之后。它只是把函数调度到当前代码之后、渲染和后续事件处理之前运行。定时器回调不会读取到循环中途的值理解了执行时机第二个问题的答案也就顺理成章回调运行时循环早已结束它读取到的i必然是最终值100000000。这还引出一个容易踩坑的经典场景如果在循环体内用setTimeout或闭包捕获循环变量捕获到的是循环结束后的最终值而不是每次迭代时的中间值。本题正是这一现象的极端示范——回调根本不会在循环期间运行自然拿不到任何中间值。宏任务与微任务谁先执行为了更精确地理解当前代码执行完之后究竟先跑什么还需要区分两类异步任务。教程在 microtask-queue 章节 中说明Promise 的.then/.catch/.finally处理器会进入内部的微任务队列microtask queue而setTimeout回调属于宏任务队列。事件循环处理完一个宏任务后会先把微任务队列清空再去处理下一个宏任务或执行渲染。看这个对比setTimeout(() alert(timeout)); // 宏任务 Promise.resolve() .then(() alert(promise)); // 微任务 alert(code); // 同步代码输出顺序为code→promise→timeout。也就是说同步代码最先执行code微任务在当前代码结束后立即执行promise宏任务setTimeout回调排在微任务之后timeout。回到本题即使把setTimeout换成 Promise结论依然成立——回调/处理器同样只能等当前同步循环跑完。区别只在于 Promise 处理器微任务会比定时器回调宏任务更早从队列中被取出执行。实战启示利用 setTimeout 拆分 CPU 密集型任务理解了回调只会在当前代码结束后运行一个非常有价值的实战应用就是拆分 CPU 密集型任务。教程 event-loop 章节的 Use-case 1 给出了完整方案。假设有一个从 1 数到 10 亿的重型计算let i 0; let start Date.now(); function count() { for (let j 0; j 1e9; j) { i; } alert(Done in (Date.now() - start) ms); } count();这段代码会让浏览器引擎长时间挂起期间无法处理任何用户点击事件甚至可能触发脚本运行时间过长的警告。原因正是事件循环的另一个细节引擎执行一个任务期间不会发生渲染也不会处理其他任务。解决办法是利用零延迟setTimeout把大任务切分成小块每完成一小块就把控制权交还给事件循环let i 0; let start Date.now(); function count() { // 只做一小部分工作 (*) do { i; } while (i % 1e6 ! 0); if (i 1e9) { alert(Done in (Date.now() - start) ms); } else { setTimeout(count); // 重新调度下一次执行 (**) } } count();执行流程是第一次运行数到 100 万第二次数到 200 万……每两次执行之间都会回到事件循环此时用户的点击、鼠标移动等事件得以插入处理浏览器界面保持可交互。教程指出拆分后的总耗时与不拆分相差无几却换来了流畅的 UI 体验。更进一步把调度语句移到count()开头还能显著提速因为浏览器对多层嵌套定时器有至少 4ms 的最小延迟限制详见下文越早调度后续每一轮就越早开始。补充setInterval 与嵌套 setTimeout 的精度差异与本题同章节的姊妹练习 1-output-numbers-100ms 展示了两种定时输出的写法setInterval版和嵌套setTimeout版。主文 article.md 进一步对比了两者的时序精度setInterval以固定间隔触发回调但回调自身的执行时间会吃掉一部分间隔导致两次调用之间的实际间隔小于设定值若回调执行时间超过间隔引擎会在回调结束后立即再次调用极端情况下变成无间隔连续调用。嵌套setTimeout下一次调用在上一次回调结束之后才被调度因此两次执行之间的间隔是固定的如稳定的 100ms。示意图如下setInterval中回调的执行时间会压缩实际间隔嵌套setTimeout保证两次执行之间间隔固定这也解释了本文主题为何重要无论是setInterval还是setTimeout回调的运行时刻都受事件循环调度约束绝不会打断正在执行的同步代码也不会精确保证延迟。浏览器对定时器的 4ms 最小延迟限制主文还强调了一个浏览器特有的细节article.mdHTML Living Standard 规定嵌套 5 层以上的定时器强制最小间隔为 4ms。零延迟自调度测试的实际输出类似1,1,1,1,9,15,20,24,30,35,40,45,50,55,59,64,70,75,80,85,90,95,100前 4 次几乎立即执行之后便出现 4ms 的强制延迟。这一限制是历史遗留大量旧脚本依赖它仅存在于浏览器Node.js 服务端没有该限制可使用setImmediate等替代方案。此外CPU 过载、标签页在后台、笔记本节能模式等都可能把最小定时器分辨率拉高到 300ms 甚至 1000ms——所有调度方法都不保证精确的延迟。总结通过这道练习我们掌握了以下核心知识setTimeout回调永远在当前同步代码执行完毕后运行——即使延迟已到、即使延迟为 0回调也只能排队等待solution.md因此在重型循环中调度的回调读取到的必然是循环结束后的最终变量值本例为100000000其底层原因是事件循环的宏任务队列模型引擎同一时刻只执行一个任务定时器回调属于宏任务必须等当前任务完成event-loop 章节宏任务与微任务有明确的优先级当前代码结束后先清空微任务队列Promise 处理器再执行下一个宏任务microtask-queue 章节这一规律可以反过来利用用零延迟setTimeout拆分 CPU 密集型任务把执行权周期性交还给事件循环从而保持页面响应、支持进度显示调度方法不保证精确延迟回调执行时间、4ms 嵌套限制、后台标签页与节能模式都会影响真实触发时机。下次再遇到定时器里的变量值为什么不对页面为什么卡死这类问题先想想事件循环回调永远在排队当前代码不结束它绝不运行。赞分享文档/教程前端【免费下载链接】en.javascript.infoModern JavaScript Tutorial项目地址https://gitcode.com/gh_mirrors/en/en.javascript.info点击查看免费下载相关推荐Metro运行时系统如何在设备上执行打包后的代码Metro运行时系统如何在设备上执行打包后的代码 Metro是React Native的JavaScript打包器负责将开发者的源代码转换为可在移动设构建工具移动开发CLIPowerToys隐藏神器清单Awake、Screen Ruler、Quick Accent等8个被低估的小工具让你快人一步PowerToys隐藏神器清单Awake、Screen Ruler、Quick Accent等8个被低估的小工具让你快人一步 PowerToys 是微软官方出桌面应用开发工具Darklang运行时代码执行环境构建Darklang运行时代码执行环境构建 概述 Darklang是一个革命性的编程语言和开发平台它将语言、编辑器和基础设施无缝集成让后端和CLI应用开发变得上一篇UE4SS终极指南解锁虚幻引擎游戏的完整修改方案下一篇终极指南30分钟打造专属精简Windows 11系统让老旧电脑焕发新生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考