ESLint 与 Prettier：团队代码规范自动化

代码风格之争（空格还是 Tab、单引号双引号、分号）在团队里永远吵不完。正确的解法是：让工具自动统一，人只做有价值的 review。

ESLint：找问题

ESLint 通过规则静态分析代码，既能管风格，更能抓潜在 bug（未使用变量、隐式全局、React/Vue 反模式）：

// .eslintrc.cjs
module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:vue/vue3-recommended',
    'prettier', // 放在最后：关闭所有与 Prettier 冲突的格式规则
  ],
  rules: {
    'no-console': ['warn', { allow: ['warn', 'error'] }],
    'vue/multi-word-component-names': 'off',
  },
}

Vue 项目用 eslint-plugin-vue，TS 项目再加 @typescript-eslint。

Prettier：管格式

Prettier 只做一件事：按固定风格重新输出代码，几乎不提供配置项——这正是它的哲学，用"没得选"终结争论：

// .prettierrc
{
  "semi": false,
  "singleQuote": true,
  "printWidth": 100,
  "trailingComma": "all"
}

两者的分工

• ESLint：代码质量规则（可能出错的逻辑）
• Prettier：纯格式（换行、缩进、引号）
• 用 eslint-config-prettier 关掉冲突规则，eslint-plugin-prettier 把 Prettier 作为 ESLint 规则跑（现代方案更推荐直接各自独立执行）

提交时自动修复

lint-staged + husky：只对暂存文件处理，commit 前自动修复，不阻塞全量构建：

// package.json
{
  "lint-staged": {
    "*.{js,vue,ts}": ["eslint --fix", "prettier --write"]
  }
}

配合 Git pre-commit 钩子，不符合规范的代码根本进不了仓库。编辑器再开保存自动修复，写代码时就无感完成。

CI 兜底

CI 流水线里跑 eslint 和 prettier --check，本地漏网的 PR 直接标红。三层防线（编辑器实时 → 提交自动修 → CI 卡关）建立后，团队代码风格问题彻底从 review 讨论中消失。