先记住这个答案
rules-of-hooks 检查普通 Hook 是否位于合法组件或自定义 Hook 中，以及是否破坏稳定调用顺序；exhaustive-deps 检查 Effect、memo 等 Hook 回调使用的响应式值是否被依赖数组覆盖，并提示部分不稳定依赖。较新的插件推荐配置还包含渲染纯度、ref 使用和编译器相关诊断，不能把整个插件等同于两条老规则。静态检查帮助发现结构问题，但无法证明订阅清理、竞态和业务行为全部正确。
- 调用规则与依赖完整性是两类检查
- 基础规则示例不等于完整 recommended 预设
- 修复同步结构优先于无理由关闭警告
先确认实际启用的规则和文件范围
安装插件并不等于规则已经运行。需要确认配置命中了实际文件扩展名、解析器能读取语法，并检查编辑器与命令行是否使用相同工作目录和配置。否则没有诊断可能只是文件被忽略。
下面的配置只启用两条基础规则并面向 JavaScript 与 JSX。配置可以保存为 eslint.config.mjs；TypeScript 项目应在现有解析器配置上组合规则，而不是把此示例当作包含所有语言支持的完整项目配置。
import reactHooks from 'eslint-plugin-react-hooks';
export default [
{
files: ['**/*.{js,jsx}'],
languageOptions: {
ecmaVersion: 'latest',
sourceType: 'module',
parserOptions: { ecmaFeatures: { jsx: true } }
},
plugins: { 'react-hooks': reactHooks },
rules: {
'react-hooks/rules-of-hooks': 'error',
'react-hooks/exhaustive-deps': 'warn'
}
}
];代码展示的是基础启用方式，语法同时适用于模块配置文件。是否把依赖警告视为阻断项由团队检查命令决定；持续集成需要失败时，可配合最大警告数限制，而不只是依赖默认退出码。
根据诊断修复语义，避免只消掉红线
条件分支中调用 useEffect，应把 Hook 留在顶层，再在其回调内部判断是否需要同步，或将分支拆成独立组件。React 的 use API 有特殊调用规则，不能把普通 Hook 的顺序限制不加区分地套到所有名字上。
依赖警告要求理解回调读取了什么：订阅房间读取 roomId，就应跟随房间变化并清理旧订阅。如果加上函数依赖后不断重跑，应考虑把函数放入 Effect、稳定必要接口或拆分职责，而不是习惯性删掉依赖。
推荐预设的覆盖与静态分析边界
在本文核对的插件版本中，推荐预设除了两条基础规则，还包含 refs、purity、immutability 等诊断以及编译器相关检查。项目升级插件时，应阅读实际预设并审阅新增提示，不能假设规则集合永远不变。
自定义 Effect Hook 可以按插件支持的设置扩展依赖检查，但正则应准确限定真正具有 Effect 语义的接口。即使所有静态检查通过，仍需验证卸载清理、输入快速切换和异步结果晚到，规则不会执行这些业务路径。
容易答错的地方
- 把 exhaustive-deps 理解成必须加所有变量
- 规则关注回调使用的响应式值以及它们的稳定性，不是要求把文件里出现的名字都塞进数组。修复时应确认读取关系，并保留编译期可分析的依赖写法，过量或错误依赖也会制造无意义同步。
- 遇到提示就添加整文件禁用注释
- 整文件禁用会掩盖以后新增的真实错误。应先理解同步目标和调用结构；确实有特定接口不被分析器理解时，限定禁用范围并说明不变量，同时用实际行为验证支撑，而不是让警告静默消失。
面试官还会怎么问？
只有 warning，持续集成一定会失败吗？
不一定。ESLint 的普通警告通常不会像错误一样自动导致失败，团队可以通过最大警告数选项等方式收紧门禁。应检查实际命令和退出码，不能把编辑器黄色提示等同于已经阻止合并。
这个插件能自动证明 Effect 不会泄漏吗？
不能。它能提示调用结构和依赖等问题，但外部资源是否一一释放、异步取消是否有效，需要运行和业务测试。尤其要检查重新订阅、卸载及旧结果返回，不能把零警告当作完整正确性证明。
使用推荐预设就等于启用了 React Compiler 吗？
不是。插件可以报告与编译器有关的诊断，但真正编译优化还需要构建流程启用 React Compiler。规则检查和编译转换是不同环节，应分别核对配置与产物，避免误判项目已经获得自动缓存。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。