代码规范实战：如何通过ESLint+Prettier提升团队协作效率

共计 2056 个字符，预计需要花费 6 分钟才能阅读完成。

当代码规范缺失时会发生什么

上周 review 同事的 PR 时，我发现同一个文件里居然混合了多种风格：

• 有的用 2 空格缩进
• 有的用 4 空格缩进
• 甚至出现了 tab 和空格混用
• 字符串引号有单引号和双引号两种写法

更可怕的是，由于缩进不一致导致 Git 合并时出现大量冲突，我们花了整整一下午才解决这个本该半小时完成的合并请求。这就是缺乏统一代码规范的代价——团队协作效率直接下降 30%。

为什么选择 ESLint+Prettier

主流方案对比

1. ESLint
2. 支持 JavaScript/TypeScript
3. 插件体系丰富（可扩展 React/Vue 等规则）

4. 既能检查代码质量也能格式化风格

5. TSLint（已弃用）

6. 2019 年起官方推荐迁移到 ESLint

7. TypeScript 团队直接维护 @typescript-eslint 插件

8. Stylelint

9. 专注 CSS/Less/Sass
10. 与 ESLint 互补使用

最终方案：ESLint（主）+ Prettier（格式化）+ Stylelint（可选）

从零配置到落地

第一步：初始化配置

安装核心依赖：

npm install eslint prettier eslint-config-prettier -D

创建.eslintrc.js：

/**
 * 基础 ESLint 配置
 * @type {import('eslint').Linter.Config}
 */
module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:react/recommended', // 如果是 React 项目
    'prettier' // 必须放在最后以覆盖冲突规则
  ],
  rules: {
    // 自定义规则示例
    'no-console': process.env.NODE_ENV === 'production' ? 'error' : 'warn',
    'react-hooks/rules-of-hooks': 'error', // 检查 Hook 规则
    'react-hooks/exhaustive-deps': 'warn' // 检查 effect 依赖
  }
};

第二步：解决与 Prettier 的冲突

安装冲突解决包：

npm install eslint-config-prettier -D

确保配置中 prettier 始终在 extends 数组最后：

extends: [
  /* 其他配置 */,
  'prettier' 
]

第三步：Git 提交时自动校验

使用 Husky + lint-staged 创建提交前钩子：

npm install husky lint-staged -D
npx husky install

添加 pre-commit 钩子：

#!/bin/sh
. "$(dirname"$0")/_/husky.sh"

npx lint-staged

配置package.json：

{
  "lint-staged": {"*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ]
  }
}

高级优化技巧

提升校验速度

1. 添加.eslintignore：

node_modules/
dist/
*.config.js

1. 启用缓存（ESLint 8.0+）：

eslint --cache --cache-location ./node_modules/.cache/eslint/

处理遗留项目

建议分阶段实施：

1. 先关闭所有规则（"rules": {}）
2. 逐步开启重要规则
3. 使用 --fix 自动修复可纠正的问题
4. 对暂时无法修改的代码使用 // eslint-disable-next-line 注释

TypeScript 专项配置

安装额外依赖：

npm install @typescript-eslint/parser @typescript-eslint/eslint-plugin -D

调整配置：

module.exports = {
  parser: '@typescript-eslint/parser',
  extends: ['plugin:@typescript-eslint/recommended'],
  rules: {'@typescript-eslint/no-explicit-any': 'off' // 根据团队习惯调整}
};

实战建议

1. 规则严苛度 ：初期建议只开启error 级别规则，逐步增加
2. IDE 集成：推荐安装 VS Code 的 ESLint 和 Prettier 插件
3. CI 集成：在 GitHub Actions 中添加 lint 步骤

- name: Run ESLint
  run: npx eslint . --ext .js,.jsx,.ts,.tsx

示例与思考

完整示例仓库：eslint-prettier-boilerplate

延伸思考

1. 微前端场景下，如何允许子应用在基础规范上扩展自己的规则？
2. Monorepo 中如何通过 extends 共享基础配置？

提示：可以考虑使用 overrides 字段和配置文件继承

最后的话

自从三周前落地这套方案，我们的代码审查时间从平均 45 分钟缩短到 25 分钟，合并冲突减少了 80%。刚开始团队成员需要适应，但两周后大家都表示 ” 回不去了 ”——毕竟谁不想把时间花在真正重要的逻辑开发上呢？