setTimeout只执行一次，适合防抖、延迟初始化等单次调度；setInterval重复执行但易导致时间不准、回调堆积、内存泄漏，需显式清除，精准轮询推荐用递归setTimeout实现。
setTimeout 只执行一次，setInterval 会重复执行——这是最本质的区别。但光记这点不够，实际写代码时，选错或用错会导致倒计时不准、请求堆积、内存泄漏甚至页面卡死。
什么时候该用 setTimeout？防抖、延迟初始化、单次异步调度
它适合“等一会儿再干一次”的场景，比如用户停止输入 300ms 后才发起搜索建议请求（防抖），或者页面加载完 1 秒再显示欢迎弹窗。
- 回调只触发一次，无需手动清理（除非你想提前取消）
- 支持直接传参：
setTimeout(greet, 1000, 'Alice', 25)，比包装函数更干净 - 即使设为
0，也不会立即执行，而是插入到任务队列末尾，让出主线程给当前同步任务 - 若想循环执行，必须在回调里再次调用
setTimeout（递归式），这样能避免执行堆积
为什么 setInterval 容易出问题？时间不准 + 回调堆积
它按固定间隔「尝试」触发回调，但不保证准时。如果某次回调执行耗时 > 间隔时间（比如接口响应慢了 1.2s，而间隔设的是 1s），下一次回调不会被跳过，而是立刻执行，造成连续触发甚至雪崩。
根据项目规范生成 React 和 Vue 组件，包括 TypeScript 类型定义、Ant Design 5 集成、Tailwind CSS 样式及 Vitest 测试文件。当用户提出创建、生成或搭建前端组件的需求时启用，例如：“帮我写一个表格组件”、“生成一个弹窗”、“create a form component”、“写一个列表页”、“生成一个下拉选择器”。该能力在以下任一场景触发：涉及 React/TSX/Vue 组件生成、UI 组件创建，或为组件生成测试文件。
- 不会因前一次未结束就跳过下一次，容易引发竞态或重复提交
- 错误不会中断定时器：哪怕回调抛错，
setInterval仍继续运行 - 必须用
clearInterval(id)显式清除，否则页面关闭前一直占内存（尤其在 SPA 中组件卸载时极易漏清） - 真正需要“精准间隔”的轮询（如心跳检测），推荐用
setTimeout递归实现
清除定时器不是可选项，是必做动作
没清的 setInterval 是前端内存泄漏的常见元凶；没清的 setTimeout 虽然只执行一次，但在组件销毁后执行回调（比如更新已卸载组件的 state），会报 React 的 Can't perform a React state update on an unmounted component 类错误。
立即学习“Java免费学习笔记（深入）”；
- 保存 ID 很关键：
const timerId = setTimeout(...)，后续才能清除 - React 中，
useEffect清理函数里必须调用clearTimeout(timerId)或clearInterval(timerId) - 不要用字符串形式传回调（如
setTimeout('doSomething()', 1000)），既不安全又无法清除（ID 对不上）
function startCountdown() {
let count = 5;
const timerId = setInterval(() => {
console.log(count--);
if (count < 0) clearInterval(timerId); // 必须主动终止
}, 1000);
}
// 更健壮的写法（避免堆积）：
function startCountdownSafe() {
let count = 5;
function tick() {
console.log(count--);
if (count >= 0) setTimeout(tick, 1000); // 下次由 setTimeout 控制时机
}
setTimeout(tick, 1000);
}
真正难的不是“怎么设”，而是“什么时候停”和“为什么不能无脑用 setInterval”。尤其在异步操作不可控（网络、渲染阻塞）的环境下，靠间隔驱动的定时器天然不可靠。
