在团队协作开发中，代码风格不统一是个老大难问题。有人喜欢用两个空格缩进，有人坚持四个；有人写注释像写诗，有人干脆一行不写。时间一长，项目代码就像拼凑出来的百家衣。为了解决这个问题，我们开始在 Git 提交时加入编码标准检查，让机器来当那个“较真”的人。
为什么要在提交时做检查？
很多人习惯写完代码再回头跑一遍格式化工具，但总有疏漏。更现实的情况是：赶需求、卡上线时间，谁还记得去手动执行 lint 命令？等到 CI 流水线报错，又得回退修改，浪费的是整个团队的时间。
把检查提前到本地提交那一刻，相当于在代码出门前加了一道安检门。不符合规范？别急着 push，先改好再说。
用 Husky + Lint-Staged 实现自动化
Husky 能让你在 Git 钩子中运行脚本，比如 pre-commit（提交前）或 commit-msg（提交信息检查）。结合 lint-staged，可以只对暂存区的文件执行代码检查和格式化。
安装依赖：
npm install --save-dev husky lint-staged启用 Husky 并配置钩子：
npx husky init然后在 package.json 中添加 lint-staged 配置：
"lint-staged": {
"*.{js,ts,jsx,tsx}": [
"eslint --fix",
"prettier --write"
],
"*.css": [
"stylelint --fix"
]
}
接着在 .husky/pre-commit 文件里写入：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
npx lint-staged
现在每次 git commit，都会自动检查你修改的文件是否符合编码规范。如果有可修复的问题，会尝试自动修复；如果仍有错误，则中断提交，提醒你处理完再提交。
实际效果
上周我们组新来了个实习生，第一天提交就触发了七八条 ESLint 错误——变量命名用了中文拼音，箭头函数前后空格也不一致。因为 pre-commit 拦住了，他当场就在编辑器里改好了。第二天再提交，顺顺利利通过。这种即时反馈比事后 Code Review 再打回去要高效得多。
不只是 ESLint
除了 JavaScript/TypeScript 的代码规范，也可以集成 Stylelint 检查 CSS，或者用 Commitlint 规范提交信息格式。比如要求每条 commit 必须以 feat、fix、docs 开头，这样后续生成 changelog 才能自动化。
Commitlint 的配置也很简单：
npm install --save-dev @commitlint/config-conventional @commitlint/cli
新建 commitlint.config.js：
module.exports = {
extends: ['@commitlint/config-conventional']
};
再在 .husky/commit-msg 中加入：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
npx commitlint --edit $1
这样一来，写个 “update readme” 这样的提交信息就会被拒绝，必须改成 “docs: update readme” 才行。
小改进带来大变化
这套机制上线一个月后，CI 因格式问题失败的次数下降了 90%。团队成员也不再为代码风格争论，编辑器保存时自动格式化，提交时自动校验，省心又省力。技术债没那么容易堆积了，项目的呼吸感反而变强了。