setTimeout只执行一次，setInterval反复执行；前者注册单次未来任务并销毁，后者以最小间隔重复调度，但不保证准时，易积压或跳过；推荐用setTimeout递归实现可控轮询。
setTimeout 只执行一次，setInterval 会反复执行——这是最本质的区别，其他所有行为差异都由此衍生。
为什么 setTimeout 不会自动重复？
它本质是“注册一个未来任务”，浏览器在延迟时间到达后，把回调函数推入宏任务队列，等当前调用栈清空后执行一次，然后这个定时器就彻底销毁了。你不会看到它偷偷再跑第二遍。
- 即使页面卡住（比如主线程被长任务阻塞），它也只会在卡顿结束后执行一次，不会“补帧”
- 返回值
timeoutId是唯一标识，必须用clearTimeout(timeoutId)才能提前中止 - 常见误用：写成
setTimeout(fn, 1000)却期望它每秒刷新状态 → 实际只会触发一次，得手动递归调用才能模拟轮询
setInterval 真的“准时”吗？
不，它只保证“至少间隔这么多毫秒”，但实际执行时机受事件循环影响。如果前一次回调执行时间过长、或主线程正忙，下一次调用会被推迟，甚至可能连续触发（当阻塞解除后，积压的任务一次性涌进队列）。
- 典型问题：用
setInterval(updateClock, 1000)做倒计时，发现跳秒或卡顿后时间错乱 - 更健壮的做法是用
setTimeout递归 + 记录基准时间，主动校准误差 - 务必配对使用
clearInterval(intervalId)，否则定时器持续占用内存，且可能在组件卸载后仍发起请求（React/Vue 中尤其危险）
参数传递和函数引用怎么写才安全？
现代浏览器支持直接传参，但要注意箭头函数或闭包带来的变量捕获陷阱：
const name = "Alice";
setTimeout(() => console.log("Hello", name), 1000); // ✅ 安全：闭包捕获当前值
let count = 0;
setInterval(() => console.log(count++), 1000); // ⚠️ 表面正常，但若多次调用 setInterval 未清除，count 会意外累加
- 推荐显式传参：
setTimeout(greet, 1000, "Bob")，比setTimeout(() => greet("Bob"), 1000)更清晰、更易清除 - 避免传字符串代码（如
setTimeout("alert(1)", 1000)）：有 XSS 风险，且无法被压缩工具处理 - 函数名直接传入时，不要带括号：
setTimeout(handleClick, 300)✅，setTimeout(handleClick(), 300)❌（后者立即执行）
什么时候该选 setTimeout 而不是 setInterval？
绝大多数需要“可控重复”的场景，setTimeout 递归反而更可靠。比如防抖、节流、动画帧控制、服务端轮询失败重试等。
立即学习“Java免费学习笔记（深入）”；
-
setInterval适合：UI 上纯粹的节奏性动作（如轮播图自动切换）、无状态心跳（ping server） -
setTimeout适合：需响应外部变化（如用户操作中断倒计时）、需动态调整间隔（第一次 1s，失败后退避到 2s、4s…）、需精确控制生命周期（组件挂载/卸载时启停） - 一个容易被忽略的细节：
setInterval的 ID 是连续整数（Chrome 中从 1 开始），而setTimeout的 ID 是递增但不连续的；但这只是实现细节，不应依赖
setInterval 当作“万能轮询工具”，结果在异步边界上翻车。 
