ESLint 代码审查

代码审查为什么需要工具介入

Review PR 时，手动逐行检查风格问题很消耗注意力。命名不一致、未使用的变量、缺少分号、误用 == 与 ===——这类问题每条都要在评论里写出来，既拖慢合并节奏，也容易因为疲劳而漏掉真正危险的缺陷。当团队规模扩大、文件数增加，靠人眼做全量检查的成本会指数级上升。

ESLint 如何介入这一流程

这个技能围绕 ESLint 的规则引擎展开，核心思路是把“检查”和“人的判断”拆开：

• 规则驱动：ESLint 通过预设规则集（如 eslint:recommended）或自定义配置（.eslintrc、eslint.config.js）定义什么是“不期望的写法”，直接在文件层面产出可定位的告警。
• 自动可修复项：部分问题（缩进、引号、分号）可以通过 --fix 自动修复，减少人工干预。
• 统一团队约定：把规范写成配置文件，所有人、所有分支共享同一套判断标准，避免“本地能过、CI 报错”的反复拉扯。
• 与编辑器 / CI 集成：本地编辑器实时提示，CI 中作为合并门禁，让问题在进入主干前就被拦截。

适用边界与注意点

• 只覆盖静态可分析问题：ESLint 无法理解运行时行为，业务逻辑错误、并发缺陷不在它的能力范围内。
• 规则不是越严越好：过度激进的规则集会产生大量噪音，团队容易“关掉告警”来图清净。建议从推荐集起步，再逐步引入团队自定义规则。
• 配置需要持续维护：升级 ESLint 主版本时，规则行为可能变化，旧配置会出现意外报错，需要配套的迁移工作。
• 不替代人工 Review：工具处理风格与常见陷阱，架构决策、可读性判断仍然需要人来把关。