无服务器部署与 CI CD 自动化
11.8 Hooks与CI CD理念
Tip
真正的负责任，是让错误根本没有机会走出你的电脑。
1. 为什么要学这个?
没有 Hooks 的世界：
- 你写了一个拼写错误
cons a = 1。 git commit->git push。- 你去冲了杯咖啡。
- 5 分钟后，邮件响了："CI Build Failed"。
- 你被全团队嘲笑（或者至少很尴尬）。
有 Hooks 的世界：
- 你
git commit。 - 终端："ESLint Error: 'cons' is not defined."
- 提交被拦截。你改好，没人知道你犯过错。
2. 核心概念：Shift Left (左移)
在软件工程中，发现错误越早，修复成本越低。
- IDE (Lint): 毫秒级反馈。
- Git Hooks (Husky): 秒级反馈 (Commit 时)。
- CI (Actions): 分钟级反馈 (Push 后)。
- Production: 灾难级反馈 (用户投诉)。
Hooks 就是你的"小区保安"。没带门禁卡 (代码格式不对)，门都不让你出。
3. 解决方案 (HOW)
1. 配置 Husky (最流行的 Hooks 工具)
npx husky-init && npm install
2. 配置 pre-commit (提交前检查)
在 .husky/pre-commit 文件里：
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
# 运行 lint-staged (只检查暂存区的文件，速度快)
npx lint-staged
3. 配置 lint-staged
在 package.json 里：
"lint-staged": {
"*.{js,ts,tsx}": [
"eslint --fix", // 自动修复 Lint 错误
"prettier --write" // 自动格式化
]
}
效果：当你 git commit 时，它会自动帮你格式化代码。如果不符合规范，commit 直接失败。
防御体系图
graph TD
Code["写代码"] -->|"Step 1: IDE 提示"| Local["本地电脑"]
Local -->|"Step 2: Pre-commit (Husky)"| Git["Git 暂存区"]
Git -->|"Step 3: CI Pipeline (GitHub)"| Cloud["云端仓库"]
Cloud -- Fail --> Reject["❌ 只有 5 分钟之后才知道"]
Git -- Fail --> FastReject["❌ 马上知道 (推荐)"]
style FastReject fill:#c8e6c9,stroke:#2e7d32
style Reject fill:#ffcdd2,stroke:#c62828
4. 真实案例
Story
"Space vs Tab" 的圣战终结者
某团队里有两个流派：Space 派 (缩进用空格) 和 Tab 派。
他们经常因为格式问题互相覆盖代码，导致 git diff 一片红，全是无意义的空格变动。
技术负责人引入了 Prettier + Husky。
结果：无论你怎么写，在你 commit 的那一瞬间，代码都会被强制格式化为团队统一标准 (比如 2 Spaces)。
战争结束了。
Vibe 心法： 我们可以争论架构，争论逻辑，但永远按照标准格式化代码。 这种机械性的琐事，交给机器去自动化。 Husky 不仅是拦截错误的网，更是统一团队语言的强制翻译器。
5. 本章小结
- Fail Fast (快速失败)：能在本地拦截的，绝不发到云端。
- Lint-staged：只检查修改过的文件，不要检查全量（太慢）。
- 互补：Hooks 是防君子不防小人 (可以被绕过)，CI 是最后的底线。