一、 为什么要建立“守门员”机制？
多人协作的项目中，如果缺乏强制手段，往往会出现：
- 风格各异： 有人用单引号，有人用双引号；有人缩进 2 格，有人缩进 4 格。
- 脏代码入库： 包含
console.log、未定义变量或临时测试代码被提交。 - Commit 信息混乱： “fix”、“update”、“111” 这种毫无意义的提交记录让版本回溯变成噩梦。
Git Hooks 就是 Git 在特定事件（如 commit、push）发生前触发的脚本，它是实现自动化校验的天然关卡。
二、 核心组件：打造你的防线
我们要构建的这套体系由三个核心工具组成：
1. Husky：Git Hooks 的“管理员”
Git 默认的 hooks 存储在 .git/hooks 目录下，该目录不会被提交到仓库。Husky 的作用就是将 hooks 脚本与项目配置关联，并同步给团队中的每一个成员。
2. lint-staged：精准打击
如果项目有上千个文件，每次 commit 都全量校验会慢得令人发指。lint-staged 的核心价值在于：只校验本次提交（Git Staged）的文件，实现秒级反馈。
3. Commitlint：规范信息的“审计师”
强制要求提交信息遵循 Angular 规范，例如：feat: 增加用户登录功能 或 fix: 修复首页闪屏问题。
三、 实战演练：5 分钟搭建全自动体系
第一步：安装核心依赖
Bash
pnpm add husky lint-staged @commitlint/config-conventional @commitlint/cli -D
第二步：初始化 Husky
执行以下命令开启 Husky，并添加一个 pre-commit 钩子：
Bash
npx husky install
npx husky add .husky/pre-commit "npx lint-staged"
第三步：配置 lint-staged
在 package.json 中配置针对不同文件的校验逻辑：
JSON
"lint-staged": {
"*.{js,ts,vue,jsx,tsx}": [
"eslint --fix",
"prettier --write"
],
"*.{scss,css,less}": [
"stylelint --fix"
]
}
第四步：配置 Commit 信息校验
创建 .husky/commit-msg 钩子，并在项目根目录新建 commitlint.config.js：
JavaScript
// commitlint.config.js
module.exports = { extends: ['@commitlint/config-conventional'] };
在钩子中关联：
Bash
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'
四、 进阶：全栈视角下的规范共享
作为一名资深工程师，你应该考虑如何在多个项目或 Monorepo 架构中复用这些能力。
- 共享配置包： 将 ESLint、Prettier、Stylelint 的配置封装成一个 npm 包（例如
@your-team/config），各个项目只需一键引用，避免配置地狱。 - CI 最后的防线： 虽然本地有 Git Hooks，但开发者仍可以通过
--no-verify绕过校验。因此，必须在 GitHub Actions 或 GitLab CI 中配置相同的校验流程，作为最后的兜底。
💡 给前端开发者的硬核贴士
- 不要过度约束： 规范是为了提效，如果配置了过于严苛的规则（比如连注释格式都要管），会打击开发者的积极性。建议从“错误预防”开始，逐步迭代到“风格统一”。
- 自动化修复是关键： 尽量配置
eslint --fix。守门员不应该只说“你错了”，而应该说“我已经帮你改好了，下次注意”。
结语
基于 Git Hooks 的全自动化体系，将团队协作从“人为口头约定”进化到了“机器自动契约”。它不仅保护了代码库的纯净，更节省了 Code Review 中大量关于格式问题的口水仗。
