很多团队已经在用 ESLint、Prettier 做代码规范检查，但真正拖慢效率的，往往不是“有没有检查”，而是“检查发生得太晚”。等到 Code Review 或 CI 才发现问题，开发者通常已经切到别的任务，回头修补的成本更高。
更直接的做法，是把检查前移到 git commit 之前：本次提交改了什么，就只检查哪些文件；有问题当场拦下，没问题再进入仓库。下面就按工具职责、安装方式和两种常见配置场景，梳理一套可直接落地的 husky + lint-staged 方案。
为什么要把 Lint 放到 commit 之前
传统流程里，代码风格检查经常放在 Code Review 或 CI 阶段执行。这种方式并非不能用，但问题在于反馈链条偏长：
- 问题发现得晚，开发者已经离开当前上下文；
- 一次提交里混入格式、语法、小错误，Review 成本会上升；
- CI 因基础风格问题失败，容易占用不必要的排查时间。
如果把检查前移到 Git 的 pre-commit 钩子，就能在提交前完成最基本的一轮过滤。这样做的收益很直接：错误更早暴露，修复更快，进入仓库的代码也更整齐。
husky、lint-staged、prettier 分别负责什么
这一套方案里，三个工具的职责最好分开理解：
prettier：负责统一代码格式，例如缩进、空格、分号等，不处理复杂逻辑判断。husky：负责管理 Git Hook，这里主要是绑定pre-commit，让提交前自动触发任务。lint-staged：负责只对 Git 暂存区里的文件执行任务，避免每次提交都全量扫描项目。
整个执行链路可以理解为：
- 开发者写完代码后先执行
git add； - 随后执行
git commit； husky捕获pre-commit事件并调用lint-staged；lint-staged找出本次暂存的文件，按预设命令逐个执行；- 如果其中任一检查失败，本次
commit会被拒绝； - 全部通过后，提交才会继续完成。
先安装 husky 和 lint-staged
把这两个工具安装到项目的 devDependencies 即可。原文给出的命令如下：
npm install husky lint-staged --sa ve-dev或者：
yarn add husky lint-staged --dev如果你项目里已经有 ESLint 或 Prettier，只需要把它们和这两个工具接起来；如果还没有，也可以先把提交前的检查链路搭好，再逐步补充规则。
只做 ESLint 检查时，package.json 怎么配
如果当前项目暂时不打算接入 Prettier，只希望在提交前完成 ESLint 检查，可以直接在 package.json 中增加对应脚本、Hook 和 lint-staged 配置：
"scripts": {
"dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js --open",
...
"eslint": "eslint --ext .js,.vue src",
"eslintfix": "eslint --fix --ext .js,.vue src",
"lint-staged": "lint-staged"
},
"husky": {
"hooks": {
"pre-commit": "npm run lint-staged"
}
},
"lint-staged": {
"**/*.{js,vue}": [
"npm run eslint"
]
},这段配置的重点有两个：
- 只匹配
.js和.vue文件； - 只执行 ESLint，不做格式化处理。
适合已经有 ESLint 规则、但还不想把格式风格统一交给 Prettier 的项目。这样至少能先把语法错误和规则违规挡在提交之前。
同时接入 Prettier 时，提交流程会多一步
如果希望在提交前先自动格式化，再继续做 Lint 检查，那么可以使用下面这组更常见的配置，尤其适合 Vue 项目：
{
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,vue}": [
"prettier --write",
"vue-cli-service lint",
"git add"
]
}
}这里的执行顺序值得单独看清：
prettier --write：先按照 Prettier 规则直接改写文件内容；vue-cli-service lint：再对格式化后的代码做语法和规范检查；git add：把格式化后重新写入的文件再次加入暂存区，确保提交内容是最新版本。
如果你不是 Vue 技术栈，也可以保持这套思路不变，只替换中间的检查命令。例如把 vue-cli-service lint 换成你项目里实际使用的 ESLint 命令即可。
.prettierrc 可以怎么写
接入 Prettier 后，通常还会补一个 .prettierrc 文件，用来明确团队代码风格。原文示例如下：
{
"trailingComma": "es5", // 尾随逗号
"tabWidth": 2, // 缩进宽度
"semi": false, // 不要句尾分号
"singleQuote": true, // 使用单引号
"end-of-line": "lf" // 换行符统一为 LF
}这几个选项主要影响的是代码外观，而不是运行逻辑。它们的价值在于让不同开发者、不同编辑器产出的代码格式尽量一致，减少无意义的格式争议。
提交失败或需要跳过检查时怎么办
完成以上配置后，每次执行 git commit，工具都会自动检查这次提交涉及的文件。
- 如果检查失败，例如 ESLint 报错，终端会打印错误信息，本次提交被拒绝；
- 如果所有任务都通过，
commit才会正常完成。
遇到特殊情况时，也可以临时跳过这套检查机制。原文给出的写法是：
git commit -no-verify实际含义是通过 --no-verify 参数跳过 Git Hook。这个参数适合应急场景使用，但不建议作为日常提交方式，否则提交前检查就失去了意义。
这套方案适合哪些项目
husky + lint-staged 的核心价值，不在于“多加了一层工具”，而在于把反馈时机提前到了开发者最容易处理问题的那一刻。对前端项目尤其明显：只检查暂存区文件，执行速度通常可控，收益却很稳定。
如果你的目标是先把代码质量门槛立起来，可以从“仅 ESLint”开始；如果团队已经明确采用统一格式规范，再补上 Prettier 自动改写，会让整个提交流程更顺手。最终效果就是：低级错误更少进入仓库，团队成员之间也更容易保持一致的代码风格。
