写了六年React才敢说，useEffect正在悄悄吃掉你的性能预算

六年前，我写下第一个React组件时，useEffect像一把瑞士军刀，能优雅地处理副作用、订阅和生命周期。但今天，当我审视一个中等规模应用的性能剖析图时，发现近三成的渲染开销和内存分配都指向了那些看似无害的useEffect。这不是React的错，而是我们逐渐把useEffect当成了“万能胶”，用它粘合逻辑、同步状态、甚至驱动业务流程。性能预算就像信用卡额度，刷的时候无感，账单来时惊人。

问题的根源在于，useEffect的默认行为是“每次渲染后都执行”。很多开发者依赖依赖数组来“控制”执行时机，却忽略了依赖数组本身就是一个运行时比较的开销，更不用说那些遗漏依赖导致的闭包陷阱和无限循环。更隐蔽的是，useEffect中常见的异步操作——比如数据获取——会创建微任务队列，这些微任务在高频更新场景下会不断堆积，拖慢主线程的响应速度。浏览器主线程的每一毫秒都弥足珍贵，而useEffect正在用“副作用”的名义悄悄预支它。

现代前端框架的演进方向是更细粒度的响应式。信号（Signal）的兴起，比如在Solid.js和Preact中，以及React自身的useSyncExternalStore，都在试图把“副作用”从组件生命周期中剥离。但很多团队依然在用useEffect模拟“状态派生”，比如在useEffect中监听某个状态变化并更新另一个状态。这种模式不仅低效，还容易导致渲染次数翻倍。正确的做法是在渲染期间计算派生状态，或者使用useMemo缓存计算结果，而不是用useEffect触发二次渲染。

另一个容易被忽视的领域是事件监听和订阅。在useEffect中注册事件监听器，如果不正确清理，会导致内存泄漏和重复绑定。而清理函数本身在每次依赖变化时都会执行，这意味着频繁的订阅/取消订阅操作。对于高频事件（如滚动、鼠标移动），更合理的做法是使用requestAnimationFrame节流，或者将监听器绑定到稳定的ref上，而不是每次渲染都重新绑定。这些细节在代码审查中往往被忽略，却直接消耗着性能预算。

那么，如何判断useEffect是否“超支”？我建议从三个维度审视：第一，统计组件中useEffect的数量和依赖数组的复杂度，超过三个useEffect或依赖超过三个变量的组件值得警惕；第二，使用React Profiler记录提交阶段的耗时，重点关注useEffect执行时间占比；第三，在开发环境启用严格模式，观察副作用是否被重复执行——严格模式下的双调用会放大问题。这些手段不需要引入复杂工具，却能快速定位性能瓶颈。

替代方案并非要完全抛弃useEffect，而是把它用在真正需要与外部系统同步的场景，比如操作DOM、订阅外部事件、手动修改浏览器API。对于数据获取，优先考虑框架提供的服务端渲染或数据加载方案，比如React的Suspense配合数据获取库，或者Next.js的服务器组件。对于状态派生，使用计算属性或useMemo。对于事件处理，直接在JSX中绑定函数，而不是通过useEffect注册。这些模式能显著减少副作用数量，让性能预算花在刀刃上。

最后，我想说，useEffect是一把利器，但利器用多了也会伤手。六年的React经验告诉我，性能优化不是事后补救，而是设计时的取舍。每次写下useEffect之前，先问自己：这个副作用是否必须与渲染同步？是否可以用事件驱动替代？是否可以用状态机管理？答案往往指向更简洁、更高效的实现。性能预算有限，别让useEffect悄悄透支它。