如何用 clearTimeout 在组件销毁时及时清理定时器防止内存泄漏
为什么 useEffect 里没清理 clearTimeout 就会内存泄漏
这其实是一个经典的React陷阱。想象一下，组件已经从屏幕上卸载了，但你在useEffect里开的定时器还在后台嘀嗒作响。问题就出在这里：定时器的回调函数通常会持有对组件内部状态、props或者是闭包变量的引用。只要定时器还在，Ja vaScript引擎就没法回收这些本该被释放的对象。
尤其是当setInterval或setTimeout的回调里调用了setState，那个熟悉的警告——“Can’t perform a React state update on an unmounted component”——就会跳出来。它的本质，是试图去更新一个已经不存在的Fiber节点，自然会出问题。
最常见的错误写法，就是只负责启动，却忘了安排“后事”：
useEffect(() => {
const timer = setTimeout(() => setCount(c => c + 1), 1000);
}, []); // 没有 return 清理函数 → 这个 timer 将“长生不老”
useEffect 清理函数必须 return 一个执行 clearTimeout 的函数
记住一个原则：React非常贴心，它会自动帮你处理善后工作。当你从useEffect返回一个函数时，React就会在组件卸载、或者这个effect因为依赖项变更需要重新运行之前，自动调用它。你的任务，就是在这个善后函数里，确保调用clearTimeout（或者clearInterval），并且传入的必须是同一个timer ID。
这里有三个关键点需要注意：
- 把
timer定义在effect内部，避免闭包捕获到旧的、已经失效的ID。 - 清理函数里一定要清晰地写上
clearTimeout(timer)。 - 别提前手快把
timer设为null或者重新赋值，否则清理的时候可能就清了个寂寞。
useEffect(() => {
const timer = setTimeout(() => setCount(c => c + 1), 1000);
return () => clearTimeout(timer); // ✅ 正确写法：返回一个清除动作
}, []);
多个定时器或动态创建时，怎么安全管理 timer ID
如果只有一个定时器，用局部变量管着就行。但现实情况往往更复杂，比如：
- 同一个effect里启动了多个
setTimeout或setInterval。 - 需要根据props的变化来动态启停定时器（比如做一个可开关的轮询功能）。
- 把定时逻辑抽象封装到自定义Hook里。
对付这些场景，推荐的做法是找一个“保险箱”——比如useRef。用一个可变的引用来统一存放timer ID，能有效避免闭包陷阱：
const timerRef = useRef(null); useEffect(() => { timerRef.current = setTimeout(() => console.log('done'), 2000); return () => { if (timerRef.current) { clearTimeout(timerRef.current); // ✅ 防止 null 导致的报错 timerRef.current = null; // ✅ 显式置空，调试时一目了然 } }; }, []);
如果需要根据依赖项（比如一个intervalMs变量）的变化来重启定时器，那得更仔细：先干净利落地清除旧的定时器，再设置新的。不然，旧的timer可能就像幽灵一样，一直残留在系统里。
useLayoutEffect 或 useInsertionEffect 能替代吗
答案是明确的：不能。定时器的清理必须和组件的生命周期牢牢绑定，必须确保在React知道组件即将卸载的那一刻被执行。而这份“保证”，只有useEffect的清理函数能提供。
useLayoutEffect的清理时机虽然和useEffect一样，但它同步执行的特性并不会给清理工作带来任何额外优势，反而可能因为阻塞渲染而带来性能问题。
useInsertionEffect就更不沾边了——它只在DOM插入前运行，压根就没有组件卸载时的清理机制，完全不适用。
这里藏着一个容易踩的坑：定时器ID虽然是number类型，但不同浏览器或环境下的返回值可能不同，有些会从0开始，甚至出现负数。所以，判断一个timer ID是否有效，别简单地用if (timer)（因为0在Ja vaScript里是falsy），更稳妥的做法是用if (timer != null)或者显式地检查typeof timer === ‘number’。
