别再靠 Code Review 纠格式了！一套自动化前端工程化方案，让 Vue 项目提交即合规

上周五下午 5 点，同事提了个 PR，被 CI 卡了 7 次：

• 缩进不对
• 多了个 console.log
• 提交信息写的是 "fix bug"
• ESLint 报了 3 个 warning

他崩溃地问："就不能在我本地就告诉我错了吗？"

我说："能------但你们没配。"

今天，我就手把手教你搭建一套 Vue 3 项目开箱即用的自动化工程化流水线，包含：

• 代码格式自动修复
• 提交信息规范校验
• Git Hooks 拦截脏提交
• CI 零配置集成

全程只需 15 分钟，从此告别"格式战争"。

---

核心工具链（2026 年推荐组合）

功能	工具	优势
代码格式化	Prettier	统一风格，无配置争议
代码检查	ESLint + TypeScript	逻辑错误 + 类型安全
提交规范	Commitlint + Husky	强制 Angular 风格 commit
本地拦截	lint-staged	只检查 staged 文件，快！
构建集成	Vite + GitHub Actions	CI 自动跑检查

关键理念：本地自动修，提交前拦截，CI 只做最终守门员

---

第一步：统一代码风格 ------ Prettier + ESLint 联合治理

1. 安装依赖

npm install -D prettier eslint @typescript-eslint/eslint-plugin eslint-config-prettier

2. 配置 .prettierrc

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100
}

3. 配置 .eslintrc.js（关键：让 ESLint 不管格式）

module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    'prettier' // ← 关闭 ESLint 与 Prettier 冲突的规则
  ],
  plugins: ['@typescript-eslint'],
  parserOptions: { ecmaVersion: 2020, sourceType: 'module' }
};

效果：

• ESLint 只管逻辑错误（如未使用变量）
• Prettier 只管格式（如引号、缩进）
• 两者不再打架！

---

第二步：提交前自动修复 ------ lint-staged + Husky

1. 初始化 Git Hooks

npx husky-init && npm install

2. 配置 package.json 中的 lint-staged

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

3. 修改 .husky/pre-commit

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

npx lint-staged

效果：

当你运行 git commit，只有你改动的文件会被自动格式化 + 修复 ，

如果有无法修复的错误（如类型错误），提交直接失败！

---

第三步：规范提交信息 ------ Commitlint

1. 安装

npm install -D @commitlint/cli @commitlint/config-conventional

2. 创建 commitlint.config.js

module.exports = {
  extends: ['@commitlint/config-conventional']
};

3. 添加 commit-msg Hook

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit $1'

现在，提交信息必须符合格式：

feat(auth): add login button
fix(api): handle timeout error
docs(readme): update installation guide

否则：git commit -m "update" → 直接拒绝！

---

第四步：CI 自动守门（GitHub Actions 示例）

在 .github/workflows/ci.yml 中添加：

name: CI
on: [push]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 18 }
      - run: npm ci
      - run: npm run lint   # 检查 ESLint
      - run: npm run format:check  # 检查 Prettier

并在 package.json 中定义脚本：

{
  "scripts": {
    "lint": "eslint . --ext .js,.ts,.vue",
    "format:check": "prettier --check ."
  }
}

效果：即使有人绕过本地 Hooks（比如 --no-verify），CI 也会拦住他！

---

最终效果：开发者体验流程图

你写代码
  ↓
保存时 → VS Code 自动格式化（通过 EditorConfig + Prettier 插件）
  ↓
git add .
  ↓
git commit → Husky 触发
    ├─ lint-staged: 自动修复 staged 文件
    └─ commitlint: 校验提交信息格式
  ↓
推送 → GitHub Actions 运行完整检查
  ↓
合并！零格式争议，零低级错误

---

最后说两句

工程化不是"加流程"，而是减少人为摩擦。

一套好的工具链，应该像空气------

你感觉不到它存在，但一旦没了，立刻窒息。

花 15 分钟配好它，

未来省下的是几百小时的 Code Review 和 debug 时间。

有没有因为格式问题吵过架？欢迎留言区分享

---

各位互联网搭子，要是这篇文章成功引起了你的注意，别犹豫，关注、点赞、评论、分享走一波，让我们把这份默契延续下去，一起在知识的海洋里乘风破浪！