pre-commit钩子+Husky是最稳定、可团队共享、跨平台的自动化验证方案；手写.git/hooks/pre-commit因不入版本控制、权限/路径/退出码等问题极易失效，而Husky通过npm script管理钩子逻辑并支持自动安装与环境适配，确保验证真正落地。
直接上结论：用 pre-commit 钩子 + Husky 是目前最稳定、可团队共享、跨平台的自动化验证方案。手写 .git/hooks/pre-commit 脚本虽可行，但无法随仓库同步，协作时极易失效。
为什么不能只靠手动配置 .git/hooks/pre-commit
Git 默认的钩子脚本存放在 .git/hooks/ 下，这个目录不参与版本控制——每次 git clone 后都是空的，团队成员必须各自手动创建、赋权、维护。一旦有人漏配，验证就形同虚设。
- 脚本权限问题：Linux/macOS 下必须
chmod +x .git/hooks/pre-commit，Windows 用户常卡在这步 - 路径硬编码风险：比如写死
/usr/local/bin/eslint，换机器就报command not found - 退出码逻辑错位：忘记
exit 1或误写成exit 0，会导致验证永远“通过”
Husky 怎么让验证真正落地
Husky 把钩子脚本转成 npm script 管理，所有配置进 package.json 或 .husky/ 目录，能被 git commit 前自动加载，且支持 Node.js 生态常用工具链。
git摸鱼周报自动化
下载
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。
- 安装后执行
npx husky install，它会在.git/hooks/pre-commit写一个轻量代理，实际逻辑走.husky/pre-commit - 验证命令建议封装成 npm script，例如：
"scripts": {"lint-staged": "lint-staged"}，再在钩子里调npx lint-staged - 避免在钩子里直接写长命令，比如不要写
npx eslint --fix src/ && npx prettier --write src/，而应拆成独立 script，方便调试和复用
验证逻辑该检查什么，才不算瞎忙
不是所有检查都适合塞进 pre-commit。核心原则是：耗时 ≤ 3 秒、只处理暂存区文件、失败时有明确修复指引。
- ✅ 推荐：运行
eslint --fix+prettier --write（配合lint-staged只扫git add的文件） - ✅ 推荐：检查
commit-msg是否符合 Angular 规范（用commitlint），防止 “update readme” 这类无效信息入库 - ❌ 慎用：全量跑单元测试（
npm test）——本地开发阶段更应依赖pre-push或 CI - ❌ 慎用：编译检查（如
dotnet build）——除非项目极小或已做增量编译优化，否则会拖慢每次提交
常见失败场景和对应修复
实际落地时，90% 的问题出在环境适配和路径判断上，不是逻辑本身。
-
Cannot find module 'eslint'：说明node_modules未正确加载，确保Husky安装时用了--save-dev，且钩子脚本里没用绝对路径调用 CLI -
husky - pre-commit hook exited with code 1：不是错误，是验证失败的正常反馈；重点看上一行输出，比如src/index.js: line 5, col 10, 'console' is not defined - Windows 下
pre-commit不执行：确认 Git Bash 是默认终端，或改用cross-env包裹命令，避免 shell 差异
真正难的不是写钩子，而是定义清楚“哪些验证必须拦住提交，哪些应该放行并告警”。比如格式问题可以自动修，但类型错误或测试失败就必须阻断——这个边界一旦模糊，开发者很快就会 git commit --no-verify 绕过，整个机制就废了。
