必须用 useRef 存储定时器 ID 并在 useEffect 清理函数中调用 clearTimeout/clearInterval；多个定时器需分域管理独立 ref，避免误删；优先用 AbortController 或 requestAnimationFrame 替代 setInterval 实现可控轮询与动画。
定时器在组件卸载时还在运行，怎么安全清除？
组件销毁后 setTimeout 或 setInterval 仍执行，是常见内存泄漏源头。关键不是“设了就忘”，而是把定时器 ID 和组件生命周期绑定。
- 用
useRef存储定时器 ID（React）或实例属性（Vue/原生），避免闭包捕获过期状态 - 在
useEffect清理函数（React）、onUnmounted（Vue）或connectedCallback+disconnectedCallback（Web Components）中调用clearTimeout/clearInterval - 不要依赖组件 state 判断是否该清，因为清理函数执行时 state 可能已不可靠；只依赖 ref 中存的 ID
多个定时器共存时，如何避免互相干扰？
一个组件里同时跑倒计时、轮询、动画帧，ID 混在一起容易误删。必须分域管理，不能只靠一个 ref。
- 为不同用途创建独立 ref：如
countdownTimerRef、pollingTimerRef、rafIdRef - 轮询类任务优先用
AbortController+fetch的 signal，比死守setInterval更可控 - 动画场景改用
requestAnimationFrame，它自动随页面可见性暂停，且无需手动清除（但需在隐藏时调用cancelAnimationFrame）
怎么实时监控定时器是否正常工作？
光清不查，等于没管。要验证定时器是否按预期启动、暂停、重启、终止。
- 在设置定时器时打日志：
console.debug('timer started:', id)，并在清理时对应输出'timer cleared' - 对关键定时器加心跳标记：比如每秒写一次
lastTickRef.current = Date.now()，外部可检查Date.now() - lastTickRef.current > 2000判断是否卡死 - 避免在定时器回调里直接修改 DOM —— 改用状态更新触发重渲染，否则监控逻辑和 UI 更新会错位
为什么 setTimeout(fn, 0) 在组件里总延迟不准？
setTimeout 不是精确计时器，尤其在组件频繁更新、JS 主线程繁忙时，实际延迟可能远超设定值。
立即学习“前端免费学习笔记（深入）”；
- 不要用
setTimeout实现高精度倒计时，改用performance.now()做时间差计算 - 如果只是“尽快执行”，确认是否真需要异步：多数场景用
queueMicrotask更轻量，且比setTimeout(fn, 0)更早进入队列 - SSR 环境下
setTimeout不可用，服务端渲染时应跳过初始化，或用条件判断typeof window !== 'undefined'
实际最难的不是启停，是判断“该不该停”——比如用户切到后台标签页，定时器该暂停；但某个长任务进度条又得继续。这种状态耦合，得靠 visibilitychange 事件 + 显式状态机来管，而不是靠一套通用清理逻辑硬套。
