React useEffect依赖数组最佳实践：setState/dispatch的依赖处理

规则准确性验证 #

你梳理的1-4条规则整体准确性很高，仅第4条有小的边界补充：

• 第1条：完全准确。仅在单个useEffect中使用的函数直接定义在effect内部即可，既不需要加入依赖数组，还能自然避免闭包问题，是最优处理方案。
• 第2条：完全准确。不依赖任何组件作用域变量的函数，提升到组件外定义后引用永久稳定，无需加入依赖数组。
• 第3条：完全准确。React官方明确保证useState返回的setter、useReducer返回的dispatcher在组件全生命周期内引用不会发生变化，加入依赖数组不会导致effect多余执行，不加入也不会有逻辑问题，两种写法都合法。
• 第4条：基本准确，可补充可选方案：如果函数不需要响应式更新，也可选择用React 18新增的useEffectEvent包裹该函数，不需要额外用useCallback封装；仅当函数需要在多个地方（比如事件回调、多个effect）复用时，才推荐用useCallback包裹后加入依赖。

场景5的最佳实践 #

你对useCallback包裹方案的判断是完全正确的，这种写法属于无意义的冗余封装，只是把依赖警告转移到了useCallback层，没有任何实际价值，完全不推荐使用。
该场景下的最优方案就是直接将从Context/自定义Hook获取的setter/dispatcher加入useEffect的依赖数组：

• 无论setter/dispatcher是直接从useState/useReducer获取，还是经过Context、自定义Hook透传，它的引用稳定性不会发生变化，加入依赖数组后永远不会触发effect的多余执行，和空依赖数组的运行效果完全一致。
• 这种写法可以直接消除linter警告，不需要额外添加注释关闭规则，也没有额外性能开销，可读性和可维护性都更高。
  如果确实不想在依赖数组中添加该值，也可以在对应行添加// eslint-disable-next-line react-hooks/exhaustive-deps注释手动关闭警告，不过这种写法需要额外加注释说明忽略原因，维护成本略高于直接加依赖的方案。

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