在React函数组件的开发中，useEffect 是我们处理副作用的利器。但你是否曾陷入过这样的困境：useEffect 的依赖项多到令人眼花缭乱，导致回调函数频繁执行，甚至引发了无限循环？这就是我们常说的“依赖地狱”。
问题的核心：不必要的依赖
想象一个场景：你需要在组件挂载后，根据某个状态 userId 来获取用户数据，同时还需要在页面标题中显示这个 userId。
function UserProfile({ userId }) {
const [user, setUser] = useState(null);
useEffect(() => {
// 副作用1: 获取用户数据
fetchUser(userId).then(setUser);
// 副作用2: 更新文档标题
document.title = `用户 - ${userId}`;
}, [userId]); // 依赖数组中只有 userId
// ... 渲染逻辑
}
在这个例子中，一切都很完美。因为两个副作用都依赖于 userId，所以我们可以将它们合并到一个 useEffect 中，并且依赖项简洁明了。
但当依赖不纯粹时...
然而，现实往往更复杂。假设我们的副作用还需要用到另一个来自父组件的回调函数 onSuccess：
function UserProfile({ userId, onSuccess }) {
const [user, setUser] = useState(null);
useEffect(() => {
fetchUser(userId).then(userData => {
setUser(userData);
onSuccess(userData); // 使用了 onSuccess
});
document.title = `用户 - ${userId}`;
}, [userId, onSuccess]); // 现在必须将 onSuccess 加入依赖
}
问题来了：如果父组件没有用 useCallback 包装 onSuccess，每次重渲染都会传入一个新的 onSuccess 引用，导致本 useEffect 被反复触发，即使 userId 并未改变。
解决方案：useEffectEvent（RFC中的新Hook）
虽然目前我们可以通过 useCallback 来稳定函数引用，但未来有一个更优雅的解决方案正在路上——useEffectEvent（目前仍在RFC阶段，但概念极具启发性）。
它的理念是：将一个你明知道其逻辑变化不需要触发effect的函数，标记为“Effect Event”。
// 注意：此为未来API的示例
function UserProfile({ userId, onSuccess }) {
const [user, setUser] = useState(null);
// 使用 useEffectEvent 包裹不依赖于effect本身的函数
const onFetchSuccess = useEffectEvent((userData) => {
onSuccess(userData);
});
useEffect(() => {
fetchUser(userId).then(userData => {
setUser(userData);
onFetchSuccess(userData); // 现在它不再需要进入依赖项
});
document.title = `用户 - ${userId}`;
}, [userId]); // 依赖项再次变得干净！
}
通过将 onSuccess 封装进 useEffectEvent，我们将其从effect的“响应式依赖”中分离出来。Effect只响应 userId 的变化，而 onFetchSuccess 内部总是能拿到最新的 onSuccess props。
总结
在等待官方新Hook的同时，理解 useEffectEvent 的概念能帮助我们更好地组织effect的逻辑。核心思想是最小化依赖，并仔细思考：哪些是真正导致副作用需要重新执行的“信号”，哪些只是副作用执行过程中需要用到的“工具”。通过合理的代码分割和 useCallback 的配合，我们完全可以提前践行这一理念，写出更清晰、更健壮的副作用代码。
