近日，前端圈一则技术话题引发热议：“别再乱用useEffect了——你写的10个里有8个不该存在”。这句话出自一位资深React开发者，但迅速在开发者社区中引发共鸣。许多前端程序员自嘲：“原来我一直在用useEffect写‘伪代码’。”那么，useEffect真的被滥用了吗？滥用它又会带来哪些隐患？正确的姿势又是什么？
滥用useEffect成“行业通病”
useEffect是React Hooks中最常用的副作用钩子，用于执行网络请求、订阅事件、操作DOM等。然而，根据多位技术博主和一线开发者的观察，大量项目中useEffect的使用率远超合理范围。有统计显示，在不少React项目中，超过70%的useEffect调用其实是多余的，甚至可以完全移除。
“很多开发者把useEffect当作‘万能补丁’，无论什么逻辑都往里塞。”全栈工程师李明（化名）告诉笔者。他曾在代码审查中发现，一个简单的状态更新、点击事件、甚至计算逻辑，都被套上了useEffect，导致代码难以阅读、难以调试。“这些滥用不仅增加了渲染次数，还可能引发无限循环、内存泄漏等严重问题。”
五大典型滥用场景
经过梳理，技术社区总结出最常被滥用的五大场景：
1. 数据获取用useEffect + useState：这是最常见的错误。很多人直接在组件内用useEffect发起fetch请求，再手动管理loading和error状态。实际上，这种方式会导致竞态条件、多余渲染，而且没有缓存和自动重试。推荐使用专门的React Query、SWR或自定义的useFetch hook。
2. 将纯计算逻辑放入useEffect：比如根据props计算衍生状态，却用useEffect更新另一个state，导致先渲染旧值再渲染新值。正确做法是使用useMemo直接计算。
3. 事件监听不及时清理：在useEffect中绑定事件，却没有在清理函数中移除，导致组件卸载后事件依然执行，引发bug。
4. 依赖数组缺失或过度包含：忘记填写依赖导致闭包陷阱，或者把所有变量都填进依赖导致频繁触发。这是React官方文档反复强调但最容易被忽略的。
5. 用useEffect同步状态：例如监听一个state变化后更新另一个state，这种“级联状态”往往可以用useReducer或状态提升来解决。
专家支招：10个里只有2个该用
“在审查自己写的代码时，我会问自己：这个useEffect真的需要吗？”React技术顾问张伟表示。他提出一个简单判断标准：如果side effect（副作用）不是必须与外部世界交互（如写数据库、发请求、操作DOM、订阅事件），那么大概率不应用useEffect。
正确的做法是：能用纯函数计算的，用useMemo或直接计算；能用事件处理解决的，直接写在onClick等处理函数中；需要数据缓存的，用官方推荐的库；需要响应式订阅的，确保清理函数正确执行。
社区反思：从“习惯性useEffect”到“思考后再写”
这场讨论的背后，是前端开发者对React设计理念的重新审视。React官方文档也曾强调：useEffect是“最后的手段”，而不是“默认选项”。
值得一提的是，最新的React Server Components和Next.js App Router更进一步减少了useEffect的使用场景——很多数据获取可以直接在服务层完成，根本不需要客户端副作用。
结语
“我清理完一个项目后，useEffect数量减少了80%，代码更清晰，性能也提升了。”一位参与讨论的开发者分享道。
技术工具永远是为业务服务的，而不是用来“堆砌”的。下次你准备写useEffect时，不妨先问自己一句：“它真的需要吗？”或许你会发现，你正准备写的10个里，至少有8个不该存在。
（完）