setTimeout只执行一次，setInterval会反复触发；前者用于单次延迟场景如防抖、延时提示，后者需手动清除且易因执行超时或异常导致回调堆积、内存泄漏。
setTimeout 只执行一次，setInterval 会反复触发
这是最本质的区别：setTimeout 是“等一会儿干一次”，setInterval 是“每隔一会儿就干一次”。前者调用后自动结束；后者一旦启动，就会持续运行，直到你手动叫停。
-
setTimeout返回一个定时器 ID，可用clearTimeout(id)取消 —— 即使不取消，它也只执行一回，不会泄漏 -
setInterval同样返回 ID，但必须配对使用clearInterval(id)，否则会一直跑，占用内存、触发多余逻辑，甚至导致页面卡顿 - 两者最小延迟都受浏览器限制（通常 ≥4ms），且实际执行时间不精确：主线程忙时，回调会被推迟到空闲时才进宏任务队列
什么时候该用 setTimeout，而不是 setInterval？
防抖、延时提示、模拟接口响应、初始化后延迟加载……这些都属于「单次延迟」场景，setTimeout 更自然、更安全。
- 用户在输入框连续打字，你想等他停 300ms 再发搜索请求 → 用
setTimeout+ 每次输入前clearTimeout防抖 - 弹窗显示 2 秒后自动关闭 →
setTimeout(() => hide(), 2000)，干净利落 - 页面加载完 1 秒再初始化某个模块 →
setTimeout(init, 1000)，无需清理
setInterval 容易出问题的三个典型坑
setInterval 看似简单，但实际项目里翻车最多：不是忘了清除，就是执行不准，或者回调堆积。
-
不主动清除 → 内存泄漏 + 逻辑错乱：比如组件卸载了，定时器还在刷接口，可能更新已销毁的 state，报
Cannot update a component while rendering -
回调执行时间 > 间隔时间 → 后续回调被挤压、连续触发：例如设了
setInterval(fetchData, 1000)，但某次fetchData耗时 1500ms，下一次不会跳过，而是立刻执行，造成“连发” -
错误未被捕获 → 定时器照常运行：哪怕回调里抛了异常，
setInterval不会停，下次还会来 —— 这会让问题更难定位
替代方案：需要稳定间隔时，优先用 setTimeout 递归调用：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
function tick() {
doSomething();
setTimeout(tick, 1000); // 下次执行前才设新定时器
}
tick();
参数和行为细节差异不可忽略
语法看着像，但传参方式和执行时机有隐性差别：
- 两者都支持额外参数传给回调：
setTimeout(cb, 1000, arg1, arg2)，比写匿名函数更干净 -
setInterval的回调如果执行出错（比如访问了 undefined 属性），错误会上抛，但定时器本身不停 —— 所以务必在回调里加try/catch -
setTimeout设置0毫秒，不代表立刻执行，只是“尽快”，它仍要排队等当前同步代码跑完 - 现代开发中，动画类重复任务应优先用
requestAnimationFrame，而非setInterval；轮询类任务建议配合 AbortController 或状态判断做条件退出
真正麻烦的从来不是“怎么写”，而是“什么时候停”和“会不会堆”。尤其在 React/Vue 组件生命周期里，setInterval 忘关是最常见的定时器 bug 来源。
