javascript定时器回调同步执行但用于协调异步任务流，核心是调度能力：在指定时间将回调加入宏任务队列；其延迟仅为最小等待时间，受事件循环影响，不保证精确性。
JavaScript 中定时器回调本身是同步执行的，但常被用来协调异步任务流——关键不在“它多强大”，而在于“它何时触发”和“它如何配合其他异步机制”。真正起作用的是它的调度能力：在指定时间点把回调加入宏任务队列，让 JS 引擎按事件循环节奏执行。
定时器不是精确时钟，而是调度信号
setTimeout 和 setInterval 的延迟只是最小等待时间，实际执行受事件循环影响。如果主线程正忙（比如在运行一个耗时 200ms 的计算），即使设了 10ms，回调也要等当前任务完成才执行。
- 不要依赖 setTimeout 实现毫秒级精准控制；适合做“至少延迟 X 毫秒后尝试执行”的调度
- 避免嵌套多层 setTimeout 模拟 setInterval，容易累积延迟或漏调用；优先用 clearInterval + 新建定时器来重置逻辑
- 若需更可靠的时间感知（如动画、倒计时显示），结合 performance.now() 或 Date.now() 计算真实经过时间，而非只信 timeout 参数
与 Promise、async/await 协同的关键：明确任务排队位置
定时器回调属于宏任务，Promise.then 回调属于微任务。这意味着：一个 setTimeout 回调里 resolve 的 Promise，其 then 会立即在本轮末尾执行，而不是等下一个宏任务。
- 想让异步操作“延后一点再开始”，用 setTimeout 包一层 Promise：setTimeout(() => resolve(), 0) 可把 resolve 推到下一个宏任务
- 想让多个异步步骤“错开执行避免阻塞”，可用 setTimeout 把部分步骤降级为宏任务，缓解微任务队列压力（例如大量 then 链可能引发 UI 卡顿）
- 注意 clearTimeout 无法取消已进入队列的回调；若 Promise 已 pending，需额外设计 cancelToken 或 abortController 配合
在复杂流程中充当“协调者”，而非“执行者”
单独靠定时器很难管理状态流转，但它能很好地衔接请求、重试、节流、超时等模式。
- 超时控制：Promise.race([fetch(...), new Promise((_, rej) => setTimeout(() => rej(new Error('timeout')), 5000))])
- 防抖：每次新操作清除前一个 setTimeout，只保留最后一次触发后的回调
- 重试逻辑：失败后用指数退避 setTimeout 发起下一次 fetch，同时限制最大重试次数
清理与内存安全不能靠“记得清除”
未清除的定时器会持续持有回调函数及其闭包中的变量，导致内存泄漏，尤其在组件卸载、模块销毁场景下。
- 每个 setTimeout 返回的 id 都应被显式保存，并在不需要时调用 clearTimeout/clearInterval
- 在类或 React 组件中，把 timerId 存为实例属性，在 componentWillUnmount / useEffect cleanup 函数中统一清理
- 避免在闭包中引用大型对象（如整个 DOM 节点树、大数组），否则即使清除了定时器，对象仍可能无法被 GC
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
