Nicholas Qin1. React副作用机制全景解读
当我们在函数组件中使用useEffect时，实际上是在告诉React："这段代码需要在组件渲染到屏幕之后执行"。这种声明式的副作用管理方式，与类组件中的生命周期方法有着本质区别。React的副作用系统建立在Fiber架构之上，通过调度机制实现了细粒度的控制。
最近在排查一个内存泄漏问题时，我不得不深入React源码探究Effect的执行机制。发现从组件的挂载、更新到卸载，React维护了一套精巧的副作用处理流程。比如在函数组件中，每次渲染都会生成新的effect对象，但React会通过依赖项比较来决定是否需要重新执行副作用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Effect核心实现流程拆解
2.1 初始化阶段：effect对象的创建
在函数组件执行过程中，当遇到useEffect调用时，React会在内存中创建一个effect对象。这个对象包含几个关键属性：
- create：副作用回调函数
- destroy：清理函数（由create返回）
- deps：依赖项数组
- tag：二进制标志位（标识effect类型）
javascript复制function mountEffect(create, deps) {
return mountEffectImpl(
UpdateEffect | PassiveEffect,
HookPassive,
create,
deps
);
}
在mountEffectImpl内部，React会将当前effect挂载到fiber节点的updateQueue链表中。值得注意的是，所有effect是以链表形式存储的，这为后续的顺序执行奠定了基础。
2.2 提交阶段：effect的调度与执行
React的渲染分为render阶段和commit阶段。effect的执行发生在commit阶段的后期，具体是在commitBeforeMutationEffects和commitMutationEffects等子阶段中。
在commitRootImpl函数中，React会执行以下关键操作：
- 调度flushPassiveEffects异步任务
- 处理layout effects（同步执行）
- 安排passive effects（异步执行）
javascript复制function commitRootImpl(root, renderPriorityLevel) {
// ...省略其他逻辑
if ((effectTag & Passive) !== NoEffect) {
scheduleCallback(NormalPriority, () => {
flushPassiveEffects();
return null;
});
}
}
这种分离设计使得浏览器可以在执行耗时副作用时保持响应性。我在实际项目中就遇到过因为同步执行大量effect导致页面卡顿的情况，后来通过React Profiler定位到问题所在。
3. Effect依赖项的精妙处理
3.1 依赖比较算法解析
React使用浅比较（shallow equal）来判断依赖项是否变化。在updateEffectImpl函数中，核心比较逻辑如下：
javascript复制if (areHookInputsEqual(nextDeps, prevDeps)) {
pushEffect(hookFlags, create, destroy, nextDeps);
return;
}
areHookInputsEqual会逐个比较数组元素，使用Object.is来判断相等性。这里有个常见的陷阱：当依赖项是对象字面量时，每次渲染都会生成新对象，导致effect不必要的重复执行。
3.2 依赖项优化实践
基于源码分析，我总结出几个优化技巧：
- 对于函数依赖，使用useCallback缓存
- 对于对象依赖，考虑拆解为原始值或使用useMemo
- 空依赖数组([])的特殊含义：仅在mount时执行
javascript复制// 不推荐写法 - 每次渲染都会重新执行effect
useEffect(() => {
fetchData({ page, size });
}, [{ page, size }]);
// 推荐写法 - 拆解为原始值
useEffect(() => {
fetchData(page, size);
}, [page, size]);
4. Effect清理机制深度剖析
4.1 清理函数的执行时机
每个effect都可以返回一个清理函数，React会在两种情况下执行它：
- 组件卸载时（对应componentWillUnmount）
- 依赖项变化导致effect重新执行前
在源码中，这个逻辑体现在commitHookEffectListUnmount函数中：
javascript复制do {
if ((effect.tag & tag) === tag) {
const destroy = effect.destroy;
effect.destroy = undefined;
if (destroy !== undefined) {
destroy();
}
}
effect = effect.next;
} while (effect !== firstEffect);
4.2 清理函数的最佳实践
根据源码行为，需要注意：
- 清理函数应该与effect逻辑对称（比如取消订阅对应建立订阅）
- 避免在清理函数中执行耗时操作，这会阻塞后续effect执行
- 清理函数必须保持稳定，不应该依赖可能变化的闭包值
javascript复制useEffect(() => {
const timer = setInterval(() => {
// do something
}, 1000);
// 清理函数要保持简单稳定
return () => clearInterval(timer);
}, []);
5. 高频问题与性能优化
5.1 Effect执行顺序问题
React保证effect按照声明顺序执行。在源码中，所有effect被维护在一个链表结构中，执行时从头到尾遍历：
javascript复制function flushPassiveEffectsImpl() {
// ...省略其他逻辑
let effect = pendingPassiveEffects;
while (effect !== null) {
const nextNextEffect = effect.next;
effect.next = null;
effect = nextNextEffect;
}
}
这意味着：
- 后声明的effect会等待前面的执行完毕
- 清理函数的执行顺序与effect相反（类似栈结构）
5.2 性能优化策略
基于源码分析，推荐以下优化手段：
- 将不相关的逻辑拆分到多个effect中
- 使用useLayoutEffect处理必须同步执行的DOM操作
- 对于复杂计算，考虑使用useMemo而非effect
javascript复制// 不推荐 - 混合关注点
useEffect(() => {
fetchData();
setupResizeObserver();
}, []);
// 推荐 - 分离关注点
useEffect(() => { fetchData(); }, []);
useEffect(() => { setupResizeObserver(); }, []);
6. 高级应用场景解析
6.1 自定义Hook中的Effect管理
当我们在自定义Hook中使用effect时，这些effect会成为调用组件effect链表的一部分。这意味着：
- 自定义Hook的effect与组件自身effect具有相同执行顺序规则
- 清理函数也会被统一管理
javascript复制function useWindowSize() {
const [size, setSize] = useState(getSize());
useEffect(() => {
const handler = () => setSize(getSize());
window.addEventListener('resize', handler);
return () => window.removeEventListener('resize', handler);
}, []);
return size;
}
6.2 竞态条件处理
在异步effect中，常见的竞态条件问题可以通过清理函数解决。React保证在下一次effect执行前，会先执行上一次的清理函数：
javascript复制useEffect(() => {
let didCancel = false;
async function fetchData() {
const result = await axios.get('/api/data');
if (!didCancel) {
setData(result.data);
}
}
fetchData();
return () => {
didCancel = true;
};
}, [query]);
这种模式在源码层面得到充分支持，因为React会严格保证清理-创建的时序关系。