计时器延迟写成零，回调仍会等待当前任务结束。延迟参数不是精确执行时刻。
本文使用ECMAScript 5.1 与浏览器 DOM，代码可放入独立演示页。JavaScript（脚本语言）的作用域、函数调用与事件调度，需要与浏览器提供的接口区分。本文主体使用当时已经可用的语法，不把语言版本和宿主环境混为一谈。
1. 从现象推到机制
浏览器执行当前脚本时，不会因为计时器到期就插入普通回调。回调需要等待事件循环取得执行机会，前面还有长任务时就继续延后。界面绘制和交互也会被过长同步代码影响。
图中的四个节点分别表示同步任务、计时到期、事件队列、界面响应。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用三行控制台输出观察同步代码与计时回调的顺序，再增加有限的计算任务。不要用死循环测试浏览器调度。
1
2
3
console.log("start");
setTimeout(function() { console.log("timer"); }, 0);
console.log("end");
先记录输入、调用位置与控制台结果，再逐个改变条件。事件和异步实验保留触发顺序，避免在生产页面执行带有未知副作用的调试代码。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 零延迟计时器 | 回调仍在当前同步代码之后 |
| 当前任务执行较久 | 计时回调会相应延后 |
| 多次计时器累积 | 不代表可以精准控制帧率 |
对照 1：零延迟计时器
回调仍在当前同步代码之后。观察时记录输出的实际先后顺序。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：当前任务执行较久
计时回调会相应延后。观察时记录任务开始结束与回调时刻。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：多次计时器累积
不代表可以精准控制帧率。观察时记录等待时间与真正执行间隔。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
动画优先考虑适合绘制节奏的机制。拆分长任务可改善响应，但拆分点仍需保证业务状态不会被其他事件看到半完成结果。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“多次计时器累积”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
