4.5.1 .rules 编码规范配置技巧

在使用 ESLint、TSLint 等工具维护项目编码规范时，.rules（通常指 .eslintrc 中的 rules 字段）是最核心的定制入口。这里总结几条真实且实用的配置技巧，帮助你让规则配置既严谨又灵活。

1. 从“推荐集”继承，只写差异规则
绝大多数项目不需要从零开始定义数百条规则。直接继承业内公认的规范（如 eslint:recommended 或 Airbnb、Standard 等），然后只显式写出与团队习惯不同的几个规则。

{
  "extends": "eslint:recommended",
  "rules": {
    "no-console": "warn",
    "eqeqeq": "error"
  }
}

这样做的好处：规则集稳定、升级成本低，且自定义规则一目了然。

2. 善用 "off"、"warn"、"error" 三级粒度

"off"：完全关闭规则（例如某些 TypeScript 项目中可以关闭 no-undef）。
"warn"：团队暂时难以全部修复但仍希望有一定提示的规则，不会阻塞 CI。
"error"：必须修复的高风险或强风格类规则，用于门禁。

注意：不要轻易把格式化类规则设为 error，交给 Prettier 自动处理更省心。

3. 利用 overrides 对特定文件类型分而治之
测试文件可以放宽部分限制，配置文件可以允许 console，类型声明文件可能需要关闭某些规则：

{
  "rules": {
    "no-console": "error"
  },
  "overrides": [
    {
      "files": ["*.test.js", "*.spec.js"],
      "rules": {
        "no-console": "off",
        "max-lines": "off"
      }
    }
  ]
}

这种写法让规则精准匹配场景，避免全局“一刀切”带来的困扰。

4. 规则参数化：用配置项而非关闭规则
很多规则提供可调整选项。例如 "max-len" 不要直接关掉，而是设定合理的行宽和忽略模式：

"max-len": ["error", {
  "code": 120,
  "ignoreUrls": true,
  "ignoreStrings": true
}]

类似地，"complexity"、"no-restricted-imports" 等都可以通过参数达到“约束但不死板”的效果。

5. 版本锁定与规则注释

在项目中固定 eslint 和插件的版本，防止规则默认值变化导致 CI 突然失败。
对于偶尔需要临时绕过规则的特例，优先使用行内注释 // eslint-disable-next-line，并在旁边写明原因，避免积累成顽疾。

6. 与 Prettier 共存时的配置原则
如果使用 Prettier 做格式化，务必安装 eslint-config-prettier 并将它放在 extends 数组末尾，以关闭所有与格式冲突的规则。此时 .rules 中只保留代码质量类规则，保持职责清晰。

掌握以上技巧，你的 .rules 配置就能在可靠性和易维护性之间找到最佳平衡。