Chrome把1毫秒延迟藏了10年，开发者今天才发现

2014年，一个工程师在Chromium代码库里埋了一行注释：「1ms是最小延迟，但我们会把它变成4ms」。这条注释在2024年才被大规模讨论——期间整整10年，无数前端开发者对着setTimeout(0)百思不得其解：为什么我的代码总要等4毫秒才执行？

这不是bug，是浏览器和开发者之间的一场默契博弈。理解它，需要从JavaScript的「单线程」本质说起。

单线程的「厨房困境」

JavaScript的设计像一家只有一个厨师的餐厅。厨师（主线程）一次只能炒一道菜，但客人（用户操作）随时会点单。如果厨师炒到一半去处理新订单，锅里的菜就糊了。

事件循环（Event Loop）就是餐厅的点餐系统。它不做菜，只负责两件事：看锅里有没有正在炒的菜（检查调用栈），以及按顺序把新订单递给厨师（把回调函数推入执行队列）。

这个模型简单到近乎粗暴，却支撑了现代Web的复杂度。问题在于：当厨师真的忙不过来时，订单该等多久？

4毫秒的来历：一场被低估的功耗战争

2009年，Mozilla工程师Robert O'Callahan在Bugzilla提交了一份报告：「高频setTimeout正在吃掉笔记本电池」。他的测试显示，当页面用1毫秒间隔轮询时，CPU无法进入低功耗状态，续航直接腰斩。

浏览器厂商的解决方案出奇一致：给定时器加「冷却期」。HTML5规范最终定稿：嵌套层级超过5层的setTimeout，最小延迟强制4毫秒。Chrome、Safari、Firefox全部照做，只是没人大声宣传。

「开发者以为自己在用高精度定时器，实际上浏览器在帮你省电。」前Chrome工程师Alex Russell在2023年的一次播客中回忆，「我们讨论过要不要在控制台警告，但担心引发恐慌性重构。」

这个妥协制造了巨大的认知断层。2019年，React核心团队发现Scheduler组件的批量更新出现不可预测的延迟，追查三周才发现是setTimeout的4毫秒陷阱。Dan Abramov在GitHub issue里写道：「我们文档里写的'16ms一帧'，底层其实可能是20ms。」

Promise和async/await：新语法，旧循环

ES2015引入Promise时，很多人以为JavaScript「摆脱」了回调地狱。真相更微妙：Promise的.then()仍然走事件循环，只是队列优先级不同。

浏览器内部至少有两条队列：宏任务（macrotask）和微任务（microtask）。setTimeout进宏任务队列，Promise回调进微任务队列。事件循环的每一轮，先清空所有微任务，再执行一个宏任务。

这个设计让async/await看起来像是「同步代码」，实际仍在切分执行权。看这段代码：

async function demo() { console.log('A'); await Promise.resolve(); console.log('B'); } demo(); console.log('C'); // 输出：A → C → B

await那一行把函数切成两半，后半段被塞进微任务队列。主线程继续跑C，等本轮同步代码走完，才回来执行B。这种「暂停-恢复」机制没有创建新线程，只是事件循环的调度魔术。

2022年，V8团队工程师Leszek Swirski在一篇技术博客中透露：实现async/await只用了不到200行C++代码，核心逻辑完全复用现有的Promise基础设施。「语法糖的成本接近于零，但开发者的心理模型彻底变了。」

从setTimeout到requestIdleCallback：浏览器在争夺什么

4毫秒延迟的争议在2019年达到顶点。Google提出Idle Detection API，想给开发者「真正的」空闲回调——不是定个时间猜浏览器忙不忙，而是浏览器主动告诉你「我现在有空」。

这个API引发了隐私争议。Mozilla反对票的理由很直接：「网站可以精确判断用户何时离开键盘」。W3C技术架构组花了18个月权衡，最终版本阉割了高精度时间戳，延迟精度降到秒级。

更具讽刺意味的是，requestIdleCallback这个「官方解决方案」至今未被Safari实现。2023年状态显示：Chrome和Edge支持，Firefox标记为「实验性」，Safari零进展。前端开发者仍在用setTimeout(0)打补丁，只是现在更多人知道它会变成4毫秒。

「浏览器厂商在性能、隐私、标准统一之间走钢丝，」W3C特邀专家Surma在2024年JSConf的演讲中说，「而开发者在下面捡碎片，拼凑出能用的工具链。」

Node.js的叛逃与回归

事件循环不是浏览器的专利。Node.js拿它管理文件I/O和网络请求，但实现细节大相径庭。浏览器有渲染管线要照顾，Node只关心效率，所以它的setTimeout精确到1毫秒——没有4毫秒限制。

这个差异曾让无数全栈开发者踩坑。2017年，npm包setimmediate的下载量突然暴涨，因为开发者发现它在浏览器和Node表现不一致：浏览器回退到setTimeout(0)，Node用更高效的原生实现。

Node 11在2018年做出一个「破坏性」改动：把定时器精度从1毫秒降到和浏览器对齐的4毫秒。社区哗然，issue区被「这是breaking change」刷屏。核心维护者James Snell的回应很干脆：「跨平台一致性比微优化更重要。」

三个月后，这个决定被部分回滚。Node 11.2恢复1毫秒精度，但新增--force-node-api-uncached选项强制4毫秒行为，供测试使用。Snell在PR评论里承认：「我们低估了生态系统的碎片化程度。」

这场拉锯战暴露了JavaScript的深层张力：它既是「写一次跑到处」的跨平台语言，又被每个宿主环境的具体约束重塑。事件循环的抽象很美，落地时全是妥协。

2024年5月，V8团队提交了一项新实验：在桌面端恢复1毫秒setTimeout精度，前提是页面处于活跃标签且用户近期有交互。条件苛刻到几乎无法预测，但方向明确——浏览器正在重新评估那场10年前的功耗战争，毕竟现在的芯片制程和2009年已是两个世界。

如果你的代码里还有setTimeout(0)，你会为了那3毫秒去检测浏览器版本吗？