摘要

  • W3C 2015 年首份公开草案引入 requestIdleCallback：网页申请在浏览器预计空闲时运行，回调收到 IdleDeadline，可用 timeRemaining() 查询还剩多少时间。
  • 2017 年与 2025 年文本沿用分工：网页拆分杂活，浏览器安排时隙。网页可设置超时以免任务久等；didTimeout 告诉它这次是等到了空闲，还是等到了期限。

网页最擅长的一件事，是把“顺手做一下”排成整天的日程。处理一批数据，给尚未打开的页面备料，写入一条本地状态，顺便整理缓存。每件都能说出理由，叠起来却足以让一次点击像在柜台排队。浏览器还要画下一帧、响应输入、处理别的任务。它偶尔有空，空多久却要看接下来发生什么。

旧办法是用 setTimeout 设个闹钟，时间到了就干活。闹钟只认识时间，不认识用户下一次点击。W3C 2015 年 9 月 17 日的首份公开草案换了一个发号方式：页面调用 requestIdleCallback，请浏览器在预计空闲的时段通知自己。浏览器送来 IdleDeadline，其中的 timeRemaining() 报告它估计还能借出多少时间。网页带着待办事项来，浏览器掌握会议室钥匙。

这个估计并非整块出租的工位。草案把一次空闲时段上限设为 50 毫秒；用户突然输入，实际窗口还能更短。懂得分寸的代码做一小段工作，看一眼 timeRemaining()，到点就把未完的部分留给下一次回调。网页必须事先把工作切得动。把一整段长计算塞进名叫“idle”的函数，跟给一辆货车贴上“轻便”标签一样，过桥时仍会压住路面。

最初文本举了逐步计算的例子：每次只算一点，更新结果，再预约下一次空闲。这不像技术宣传片里的高速冲刺，更像厨师趁灶台空出半分钟切几片菜。它的意义在于让紧急事先通过。浏览器知道下一帧和输入队列的压力；网页知道自己的菜该切多细。双方都要按这个分工做事，页面才会显得轻快。

2017 年 1 月的候选推荐文本和同年 10 月的拟议推荐文本保留了另一道难题：如果一直没有空，后台任务会排到什么时候？网页可以给请求设置 timeout。到期后，回调会获得运行机会，didTimeout 表示它是被期限催来的。这个按钮很诱人。每个脚本都觉得自己的杂活再等下去就要出大事；一起按下时，浏览器刚腾出的走廊又变成早高峰。

W3C 发布历史把 2015 年首稿、2017 年几个阶段和后续修订串起来。2025 年 5 月 21 日的工作草案依旧让浏览器判定空闲时段，让回调读取期限。十年后，关键问题仍然朴素：共同的时钟由谁看，某个网站的杂活由谁挑。浏览器不能替网站判断哪条本地数据值得预备；网站也看不到浏览器全部即将到来的输入和绘制安排。

站在读者一边，最好的结果是看不见这套安排。点一下，页面就答应；停顿间，后面的工作也悄悄推进。若页面迟钝，先查那些“空闲”回调到底运行了多久，有多少次靠超时硬挤进来。空闲时间像地铁门关闭前的几秒，适合让人下车，不适合搬一套沙发。