别只会 setTimeout(fn, 1000)，这才是现代前端该用的调度姿势

做页面交互时，你肯定遇到过这种场景：用户狂点提交按钮，接口请求像雪片一样飞出去；或者想等某个动画彻底跑完再触发动作，结果画面明显卡顿。这时候，把目光投向原生的定时器，不是让你去写倒计时，而是把它当成任务调度员。很多人对它的印象还停留在“延迟执行”，其实稍微换个思路，就能解决大半开发里的节奏控制问题。

基础写法大家闭着眼都能敲出来，但传参环节经常翻车。如果直接在定时器内调用带参函数，逻辑会在注册时刻就立刻执行。正确的做法是把额外参数紧跟在时间戳后面，或者用箭头函数包裹执行体。setTimeout(() => fetchData(userId), 500) 这种结构最稳妥，既保留了原始函数的运行上下文，又完全符合规范。遇到需要传递配置对象的情况，记得提前做浅拷贝，避免闭包悄悄引用到后续被重写的状态。

循环里挂定时器是新手很容易踩坑的地方。如果你指望回调里拿到循环变量的终值，大概率会撞上预期不符。JS 的单线程模型决定了这些任务全部塞进宏队列，等主线程空闲才按顺序兑现。解决起来并不复杂，利用块级作用域锁定每次迭代的快照。现在的主流环境直接使用 let 声明循环索引即可自动隔离，不用再去折腾立即执行函数。

真正提升代码质感的用法在于组合拳。把高频触发的事件收敛成单次执行，不需要依赖第三方库，手动实现防抖的核心就是掐掉上一轮的排期，重新投递新任务。输入框模糊搜索、窗口 resize 监听都依赖这套机制。另外，复杂业务里经常需要串行走流程，前一步数据就绪后才走下一步。与其维护一串串看不懂的缩进回调，不如让每个定时器返回 Promise，配合 async/await 把异步链条拍平成线性代码，调试时打断点也清晰得多。

页面切换或组件卸载时，残留的定时器还在后台默默消耗性能，内存泄漏往往就是这么发生的。养成记录定时器句柄的习惯，在生命周期清理阶段统一执行 clearTimeout，比在业务代码里到处埋释放逻辑要干净利落。当然，它也不是万能钥匙。如果是为了追赶屏幕刷新率做视觉平滑，交给 requestAnimationFrame 更专业；如果是网络请求的超时拦截，Fetch 的 AbortController 已经能全面接管旧时代的轮询方案。定时器就该安分待在自己的舒适区——处理离散的时间片分配。

工具从来不存在绝对的优劣，只有用得顺手还是生搬硬套。把 setTimeout 从“机械的等待”还原成“精确的排期”，你的项目节奏会踏实很多。下次再面对交互动画抢跑、事件过载堆积的时候，不妨先理清业务到底需要卡准哪个时间节点。方向对了，剩下的交给引擎去调度。