setTimeout是浏览器和Node.js中的全局函数，用于延迟执行回调，接收函数、毫秒数及可选参数；需用clearTimeout清理以防内存泄漏和错误；节流需状态控制，跨平台使用时注意DOM限制。
setTimeout 基本调用方式和参数含义
setTimeout 是浏览器环境下的全局函数，用来在指定毫秒后执行一次回调。它接收至少两个参数：第一个是待执行的函数（或字符串，不推荐），第二个是延迟毫秒数。第三个及以后的参数会作为回调函数的实参传入。
- 毫秒值为
0并不等于“立刻执行”，而是“尽快在下一次事件循环中执行”，受主线程阻塞影响 - 回调函数中的
this默认指向window（非严格模式）或undefined（严格模式），建议显式绑定或用箭头函数 - 不要传字符串如
"alert(1)"，存在 eval 风险且无法访问闭包变量
setTimeout(() => {
console.log('3秒后运行');
}, 3000);
清除 setTimeout 防止内存泄漏或误触发
每次调用 setTimeout 都返回一个唯一数字 ID，必须用 clearTimeout 主动清理，否则即使页面逻辑已退出，回调仍可能在后续触发（尤其在组件卸载、AJAX 中途取消、表单重复提交等场景）。
- React/Vue 等框架中，组件销毁前未清理
setTimeout，会导致 setState 或 this.setState 报错（Can't perform a React state update on an unmounted component） - 多次连续调用未清理，可能累积多个定时器，造成意料外的多次执行
- 清理操作应放在明确的“生命周期结束点”，比如
useEffect的返回函数、beforeUnmount钩子、或手动控制的开关逻辑里
let timerId = setTimeout(() => {
doSomething();
}, 2000);
<p>// 后续某处决定取消
clearTimeout(timerId);
timerId = null; // 可选，便于判断是否已清除</p>setTimeout 实现节流（throttle）时的典型错误
很多人想用 setTimeout 防抖（debounce）或节流，但写错逻辑导致行为异常。节流要求“固定间隔内最多执行一次”，常见错误是每次调用都新建定时器而没判断状态。
- 错误写法：
setTimeout每次都无条件设置，导致上一个还没执行就被覆盖，最终只执行最后一次 - 正确做法：用一个标志位（如
isThrottled）或保存timerId并检查是否为null - 注意：节流与防抖目的不同——节流保频率，防抖保终态；别把
debounce的逻辑套到节流场景里
let throttleTimer = null;
function throttledHandler() {
if (throttleTimer) return;
throttleTimer = setTimeout(() => {
console.log('执行核心逻辑');
throttleTimer = null;
}, 100);
}
Node.js 中不能直接用 setTimeout？
setTimeout 在 Node.js 全局作用域中也存在，行为基本一致，但要注意：
立即学习“前端免费学习笔记（深入）”；
- Node.js 中没有 DOM，所以不能操作
document或element.style等前端专属 API - 如果你在写跨平台工具（如 CLI 脚本），需确认运行环境：用
typeof window !== 'undefined'判断是否在浏览器 - 某些打包工具（如 Webpack）或 SSR 框架（如 Next.js）中，服务端渲染阶段执行代码时
setTimeout仍有效，但不会触发 UI 更新——这点容易被忽略，以为“没生效”，其实是执行了但没视觉反馈
真正容易出问题的地方，是把依赖 DOM 的逻辑（比如 element.classList.add）和 setTimeout 一起写在服务端入口里，结果抛出 ReferenceError: document is not defined。
