husky 与 lint-staged 是什么
husky 负责管理 git 钩子，lint-staged 负责只对暂存文件运行检查：两者组合是前端仓库里最常见的一套提交守卫。它把检查范围压到本次改动上，既能在提交前拦住低级问题，又不会让全量检查把提交拖到几十秒。
基本信息
| husky | 管理 git 钩子，例如提交前钩子 |
|---|---|
| lint-staged | 只处理暂存文件，控制耗时 |
| 配置位置 | package.json 里的 lint-staged 段 |
| 分工 | 格式与自动修复走钩子，全量检查留给 CI |
典型使用场景
- 前端仓库统一提交质量：一次安装，全员生效
- 提交前自动格式化：只对改动的文件跑格式化工具
- 关联检查：对改动文件跑相关的单测与类型检查
- 与 CI 配合：钩子给即时反馈，流水线做兜底
- 老旧仓库分阶段：先只加格式化，再逐步加检查
配置时注意什么
- 只处理暂存文件，避免全量检查拖慢提交
- 钩子里的命令与 CI 保持一致
- 允许确有必要时跳过，但要记录原因
- 钩子脚本本身也要入库管理
lint-staged 配置
lint-staged 配置
// package.json
{
"lint-staged": {
"*.{js,ts}": ["eslint --fix", "prettier --write"],
"*.md": ["prettier --write"]
}
}常见问题与处理
| 问题 | 处理方向 |
|---|---|
| 提交动辄几十秒 | 把全量检查移出钩子，只保留暂存文件 |
| 钩子未生效 | 确认钩子文件已生成并纳入版本管理 |
| 本地与 CI 结论不一致 | 对齐工具版本与配置文件 |
| 多人并行改动频繁互相覆盖 | 缩小钩子范围，只留必要检查 |
只处理暂存文件是关键：全量检查在大型仓库里会把提交时间拖到让人干脆放弃钩子。
在评审中的用法：钩子跑过之后，评审者可以假设格式与浅层问题已经处理，注意力留给设计与边界条件。
钩子里只放能自动修复的命令：需要人工判断的检查放进流水线，否则提交会被反复卡住。
本地钩子规则与 CI 不一致：两边结果互相矛盾，修复成本翻倍。