# Husky 与 lint-staged：前端代码质量的守护者
1. 他是什么
想象一下，你正在准备一场重要的晚宴。在客人到来之前，你会检查餐桌是否摆正、餐具是否清洁、食物是否新鲜。Husky 和 lint-staged 就是前端项目中的这种“餐前检查员”。
Husky是一个工具，它允许你在 Git 操作的关键时刻（比如提交代码前）自动运行特定的检查脚本。就像门卫在客人进入宴会厅前检查他们的着装是否得体。
lint-staged则是 Husky 的得力助手，它专门负责检查那些“即将被提交的代码文件”。不是检查整个项目，而是只检查那些有变动的文件，就像只检查新摆上桌的餐具，而不是整个厨房的所有器皿。
这两个工具通常配合使用，在代码提交到仓库前自动执行代码质量检查，确保进入版本库的代码符合团队约定的规范。
2. 他能做什么
2.1 自动化代码质量检查
在开发者执行git commit命令时，Husky 会自动触发预设的钩子（hook），运行 lint-staged。lint-staged 则会对暂存区（staged）的文件运行指定的检查工具，比如：
- ESLint：检查 JavaScript/TypeScript 代码的语法和风格问题
- Prettier：自动格式化代码，保持统一的代码风格
- Stylelint：检查 CSS/SCSS 等样式文件的规范
- 测试用例：运行相关的单元测试
2.2 防止低质量代码进入仓库
如果检查发现代码有问题，提交过程会被中断。就像安检门发现违禁品时会发出警报并阻止通过。开发者必须修复所有问题后才能成功提交代码。
2.3 统一团队代码风格
无论团队中有多少开发者，每个人的代码提交前都会经过同样的质量检查。这就像工厂的质检流水线，确保每个出厂产品都符合标准。
2.4 提高代码审查效率
当基础代码规范问题在提交前就被自动解决后，代码审查者可以更专注于逻辑、架构等更重要的问题，而不是纠结于缩进、分号等格式问题。
3. 怎么使用
3.1 安装
# 安装 huskynpminstallhusky --save-dev# 初始化 huskynpx husky init# 安装 lint-stagednpminstalllint-staged --save-dev3.2 配置 package.json
{"scripts":{"prepare":"husky install"},"lint-staged":{"*.{js,jsx,ts,tsx}":["eslint --fix","prettier --write"],"*.{css,scss}":["stylelint --fix","prettier --write"]}}3.3 创建 Git 钩子
# 创建 pre-commit 钩子npx huskyadd.husky/pre-commit"npx lint-staged"3.4 工作流程
- 开发者修改代码后执行
git add .将文件加入暂存区 - 执行
git commit -m "提交信息" - Husky 自动触发 pre-commit 钩子
- lint-staged 对暂存区的文件运行配置的检查命令
- 如果所有检查通过，提交成功；如果有问题，提交被阻止
4. 最佳实践
4.1 渐进式引入
对于已有项目，不要一次性启用所有严格的检查规则。可以从最基本的规则开始，逐步增加。就像健身，从轻量级开始，逐渐增加强度。
4.2 只检查暂存文件
lint-staged 的核心优势就是只检查即将提交的文件，而不是整个项目。这大大提高了检查速度，特别是对于大型项目。
4.3 合理的错误处理
配置检查命令时，使用--fix参数让工具自动修复可自动修复的问题。对于无法自动修复的问题，提供清晰的错误信息，帮助开发者快速定位问题。
4.4 与 IDE 集成配合
虽然 Husky + lint-staged 在提交时进行检查，但最好在开发过程中就使用 ESLint、Prettier 等工具的编辑器插件。这样可以在编写代码时就发现问题，而不是等到提交时。
4.5 团队统一配置
将 Husky 和 lint-staged 的配置纳入版本控制，确保团队所有成员使用相同的检查规则。可以通过共享的配置文件或继承共同的规则集来实现。
5. 和同类技术对比
5.1 与纯 Git 钩子对比
原生 Git 钩子：Git 本身支持钩子功能，但需要手动编写脚本，配置相对复杂，且难以在团队中同步配置。
Husky：提供了更简单的配置方式，更好的跨平台支持，并且配置可以轻松纳入版本控制，便于团队共享。
5.2 与持续集成（CI）检查对比
CI 检查：在代码推送到远程仓库后，在 CI 服务器上运行检查。问题是发现问题时，代码已经进入仓库，需要额外的修复提交。
Husky + lint-staged：在代码进入本地仓库前就进行检查和修复，确保提交到远程仓库的代码已经是符合规范的。
两者不是替代关系，而是互补关系。通常建议本地提交前检查 + CI 检查双重保障。
5.3 与 pre-commit 框架对比
pre-commit（Python 生态）：Python 社区流行的类似工具，功能强大，但主要针对 Python 项目。
Husky：专为 Node.js 和前端项目设计，与 npm/yarn 工作流集成更好，配置更符合前端开发者的习惯。
5.4 与其他 Node.js 钩子工具对比
simple-git-hooks：更轻量级的替代方案，但功能相对较少。
lefthook：性能更好，配置更灵活，支持并行执行任务，但学习曲线稍陡。
Husky：目前最流行、社区最活跃、文档最完善的选择，适合大多数项目。
总结对比
| 工具/方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Husky + lint-staged | 配置简单，社区活跃，前端生态集成好 | 对于超大项目可能稍慢 | 大多数前端项目 |
| 纯 Git 钩子 | 无需额外依赖 | 配置复杂，团队同步困难 | 简单项目或个人项目 |
| CI 检查 | 确保远程仓库代码质量 | 反馈延迟，代码已入库 | 所有项目（作为补充） |
| lefthook | 性能好，功能强大 | 学习成本较高 | 对性能要求高的大型项目 |
Husky 与 lint-staged 的组合在前端开发中已经成为事实上的标准配置。它们像是一道质量防线，在代码进入版本库前自动执行检查，既保证了代码质量，又减少了人工检查的负担。对于团队协作项目，这种自动化检查机制尤为重要，它能有效统一代码风格，提高代码的可维护性。
