React Hooks的exhaustive-deps代码检查规则是否始终合理？

这个问题其实非常常见，不是你的设计有问题，而是react-hooks/exhaustive-deps规则本身的局限性导致的——它没法区分哪些依赖是「弱依赖」（即变更时不需要触发effect），只能机械地检查所有在effect内部用到的变量。

先拆解你的场景：

• openProject和setProjectTab是store提供的常量函数，引用不会变化，把它们加入依赖数组完全没问题，这部分规则的提示是合理的。
• 但openProjects是全局状态数组，每次状态更新都会生成新的引用；而你的effect本身就会触发openProject或setProjectTab，进而导致openProjects更新——如果把它加入依赖数组，必然会触发无限循环，这就是规则的“一刀切”问题。

可行的解决方案 #

1. 针对性忽略ESLint警告（简单直接）

如果你确定openProjects的变更不需要触发这个effect，可以在effect末尾添加ESLint注释来忽略该警告，但一定要加上注释说明原因，方便后续维护：

useLayoutEffect(() => {
  if(find(openProjects, { id })) setProjectTab(id, tab)
  else openProject(id, tab)
}, [tab, openProject, setProjectTab])
// eslint-disable-next-line react-hooks/exhaustive-deps -- openProjects变更会触发无限循环，此处无需监听

注意：只忽略这一行的特定规则，不要全局禁用，避免错过其他真正的闭包问题。

2. 重构逻辑，避免直接依赖状态数组（更优雅）

既然问题出在直接依赖openProjects，可以把“判断项目是否已打开”的逻辑封装到store内部，比如新增一个isProjectOpen(id)方法：

// 在store中添加方法
const isProjectOpen = (id) => find(openProjects, { id })

// 在组件中使用
const Project = ({ id, '*': tab }) => {
  const [{ }, { openProject, setProjectTab, isProjectOpen }] = useStore()
  useLayoutEffect(() => {
    if(isProjectOpen(id)) setProjectTab(id, tab)
    else openProject(id, tab)
  }, [id, tab, openProject, setProjectTab, isProjectOpen])
}

这样一来，effect依赖的是isProjectOpen这个常量函数（引用不变），既符合规则，又不会触发无限循环，同时把状态相关的逻辑收拢到store里，更符合Redux类状态管理的最佳实践。

3. 使用useRef缓存状态（适合特殊场景）

如果不想改动store，可以用useRef缓存openProjects，但要注意这种方式可能拿到过时的状态，只适合你确定effect执行时机能保证拿到最新值的场景：

const Project = ({ id, '*': tab }) => {
  const [{ openProjects }, { openProject, setProjectTab }] = useStore()
  const openProjectsRef = useRef(openProjects)
  
  // 同步ref到最新状态
  useEffect(() => {
    openProjectsRef.current = openProjects
  }, [openProjects])
  
  useLayoutEffect(() => {
    if(find(openProjectsRef.current, { id })) setProjectTab(id, tab)
    else openProject(id, tab)
  }, [id, tab, openProject, setProjectTab])
}

这种方式绕开了直接依赖openProjects，但多了一层ref同步，复杂度稍高，不如前两种方案简洁。

总结 #

exhaustive-deps规则是为了帮我们避免闭包过时的bug，但它不是银弹——当遇到依赖变更会触发无限循环、且该变更确实不需要触发effect的场景时，合理地忽略警告或重构逻辑都是可行的，不用怀疑自己的设计。

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