React实现计时器为何推荐使用useEffect，而非仅依赖useState？

1. 为何很少采用仅useState+普通函数的计时器方案？ #

• 最核心的原因是默认缺少自动清理机制，容易出现内存泄漏：选项1的timer ID存在useRef中，仅在手动调用暂停、重置时才会清理，如果你忘了在组件卸载时额外写useEffect清理interval，组件销毁后timer还会继续运行，持续调用setTime触发无效更新，占用内存。而选项2的useEffect会在依赖变化、组件卸载时自动执行返回的清理函数，天生避免了这个问题，对开发者更友好，也不容易出bug。
• 你提到的性能差异几乎不存在：首先你给出的选项2写法本身有错误——它的依赖数组错误加入了time2，才会导致每次time2更新都会销毁旧interval、创建新interval，出现你说的频繁挂载卸载的问题。正确的选项2依赖数组只需要填isActive即可：因为setTime2用的是函数式更新，直接读取上一轮的prevTime，不需要依赖外部的time2变量。修正后，useEffect只会在isActive（启动/暂停）切换时才会执行，和选项1的timer创建销毁频率完全一致，性能没有任何差别。
• 清理需求的满足：选项1如果手动补充组件卸载时的清理逻辑，确实也能满足清理要求，但需要开发者额外写代码，漏写概率极高，而选项2不需要额外处理就能覆盖所有清理场景。

2. 两种方案的精度对比 #

• 两种方案如果写法正确，精度没有任何差异：它们底层调用的都是浏览器的setIntervalAPI，本身的计时精度由浏览器事件循环决定，只要主线程有其他阻塞任务（比如大量计算、重渲染），都会出现计时漂移，和是否用useEffect没有关系。
• 你观察到的选项2更慢、滞后的情况，就是前面提到的错误依赖导致的：原选项2把time2加入依赖，每次time2减1都会触发useEffect重新执行，先清掉上一个interval，再创建新的interval，相当于每过1秒就把计时器重置一次，这个销毁重建的过程会累积误差，时间越久滞后越明显。把选项2的依赖改成[isActive]后，interval只会在启动时创建一次，运行过程中不会被销毁重建，表现和选项1完全一致。
• 补充：如果需要高精度计时器，不管用哪种方案都需要做时间差校正（每次tick时用当前时间减去初始时间计算实际流逝的时长，而不是单纯每次减1），或者用requestAnimationFrame实现，和这两种实现模式无关。

内容的提问来源于stack exchange，提问作者Jon