## Husky 脚本管理：一个资深工程师的实践笔记
在团队协作开发中，代码提交前的检查环节常常让人头疼。每个人都可能因为疏忽，把一些本不该提交的代码推送到仓库里，比如忘记运行测试、代码格式混乱，或者不小心提交了调试用的console.log。这些问题虽然不大，但积累起来会让代码库变得难以维护，也给其他同事带来不必要的麻烦。
Husky 就是为了解决这类问题而生的工具。它不是什么高深莫测的黑科技，更像是一个守在代码仓库门口的“自动检查员”，在你执行git commit或git push等操作时，自动触发一些我们预设好的脚本，比如运行测试、检查代码格式、验证提交信息规范等等。如果检查不通过，这次提交就会被拦下来，直到问题被修复。
Husky 到底是什么
简单来说，Husky 是一个 Git 钩子（Git Hooks）管理工具。Git 本身自带了一套钩子机制，允许我们在特定的 Git 事件（如提交、推送）发生时执行自定义脚本。这些钩子脚本存放在项目的.git/hooks目录下。但这里有个问题：.git目录通常不被纳入版本控制，也就是说，每个克隆项目的人都需要手动配置一遍这些钩子，这在实际团队协作中几乎不可行。
Husky 巧妙地解决了这个痛点。它把这些钩子脚本的配置移到了项目根目录下（比如package.json或专门的配置文件里），使其可以跟随项目代码一起被版本管理。这样一来，只要团队成员安装了项目依赖（Husky 通常作为开发依赖被安装），这些自动化的检查就会自动生效，保证了团队内检查标准的一致性。
它能为我们做什么
想象一下团队开发中的几个常见场景。新来的同事可能不熟悉项目的代码规范，提交的代码缩进混乱；有人修改了核心模块，但忘记运行相关的单元测试；或者提交信息写得很随意，过了一周谁也记不清那次提交到底改了啥。这些问题靠口头提醒或者代码审查事后发现，成本都比较高。
Husky 的作用就是把这些事后的检查，变成事前的自动门禁。最常用的两个钩子是pre-commit和commit-msg。
在pre-commit阶段，我们可以让 Husky 运行代码格式化工具（如 Prettier），确保所有待提交的代码风格统一；运行静态代码检查（如 ESLint），捕获一些潜在的语法错误或代码异味；运行单元测试，确保新的改动没有破坏现有功能。这相当于在代码出门前，强制给它做一次“体检”。
在commit-msg阶段，我们可以用 Husky 来校验提交信息的格式。比如要求必须遵循“类型(范围): 描述”的格式（类似 Angular 提交规范），或者要求描述部分不能太简短。这能让git log的历史记录清晰可读，便于日后回溯问题和生成变更日志。
怎么开始使用它
现在 Node.js 项目中使用 Husky 已经非常方便了。首先通过 npm 或 yarn 将其安装为开发依赖。之后，运行一条初始化命令，它会在项目根目录下创建一个.husky文件夹，用来存放我们定义的钩子脚本。
接下来，我们需要在.husky目录下创建具体的钩子文件，比如pre-commit。在这个文件里，我们可以直接写入需要执行的 shell 命令。例如，你可以写上npm run lint和npm run test。这样，每次执行git commit时，Husky 都会先触发这个文件里的命令，只有所有命令都成功执行（返回退出码0），提交才会继续进行。
为了让团队其他成员也能自动启用这些钩子，一个常见的做法是在package.json的scripts里定义一个prepare脚本（内容通常是husky install）。这样，每当有人执行npm install安装完所有依赖后，prepare脚本会自动执行，完成 Husky 的安装和钩子设置，整个过程无需人工干预。
一些值得注意的实践细节
虽然 Husky 用起来简单，但想让它发挥最大效用，避免成为开发流程的绊脚石，还是有一些细节需要注意。
钩子里运行的脚本应该尽可能快。没人愿意等上几分钟才能完成一次代码提交。因此，在pre-commit钩子里，通常只对本次提交所修改的文件进行检查和格式化，而不是对整个项目全量操作。一些工具如lint-staged就是专门配合 Husky 来实现这个目的的，它可以只对 Git 暂存区（staged）的文件执行指定的命令。
另一个关键是失败信息的友好性。当钩子脚本执行失败时，应该给出清晰明确的错误提示，告诉开发者具体是哪里出了问题、应该如何修复。一个只输出“脚本执行失败”的钩子，会让人非常沮丧。
对于团队项目，建议把 Husky 的配置（即.husky目录）也提交到版本仓库中。同时，在项目的贡献者指南（如CONTRIBUTING.md）里简单说明一下项目使用了提交前检查，并列出会具体运行哪些检查，让新成员有个心理预期。
有时，我们确实需要临时跳过这些检查（比如尝试某个临时的调试方案）。Husky 也支持通过环境变量或 Git 的-n选项来跳过钩子执行，但这应该被视为例外而非常规操作。
看看它周围的其他选择
在 Git 钩子管理这个领域，Husky 是目前 Node.js 生态里最主流的选择，但它并非唯一。类似的工具还有pre-commit（一个用 Python 编写的通用框架）和lefthook（用 Go 编写，强调执行速度）。
与它们相比，Husky 最大的优势在于其与 Node.js 生态的深度集成。对于前端或 Node.js 后端项目，项目本身已经基于package.json和 npm scripts 来管理构建流程，那么引入 Husky 几乎是无缝的，学习成本很低。它的配置方式直观，社区庞大，遇到问题也容易找到解决方案。
lefthook等工具可能在执行速度或跨语言支持上有其优势，但对于一个已经深度依赖 Node.js 工具链的项目来说，引入另一种语言和包管理工具可能会增加复杂性。技术选型往往是在满足需求的前提下，选择最契合当前技术栈、对团队打扰最小的那个方案。
说到底，Husky 这类工具的价值，不在于技术本身有多复杂，而在于它以一种轻量、自动化的方式，将良好的开发实践固化到了团队的日常流程中。它让代码规范从一份写在文档里的要求，变成了每次提交时自然而然发生的动作。长期来看，这种对细节的自动化守护，对于维持一个大型项目代码库的整洁与健康，其贡献是无声却巨大的。
