vscode中需通过模板引导+钩子校验实现规范提交：先创建.gitmessage模板并执行git config commit.template .gitmessage启用；再用husky安装commit-msg钩子，调用@commitlint/cli校验，确保type、subject等符合规则。
VSCode里怎么让提交信息不乱写
直接靠人自觉写规范提交，基本等于没规范。VSCode本身不校验git commit -m内容，必须靠外部工具拦截。核心是两层：模板引导 + 钩子校验。
模板只起提示作用，真正拦住不合规提交的是commit-msg钩子。推荐用@commitlint/cli配合husky，配置commitlint.config.js指定规则，比如强制type必须是feat、fix等预设值，subject长度不能超50字符。
- 模板文件（如
.gitmessage）要放在项目根目录，再执行git config commit.template .gitmessage -
husky初始化后，手动创建.husky/commit-msg脚本，内容为npx --no-install commitlint --edit $1 - VSCode的Git面板提交时，会走同一套Git流程，所以也能被钩子拦截
pre-commit钩子该不该格式化代码
应该，但必须分清阶段：提交前格式化代码，和提交信息校验是两件事，别混在一起。很多人把pre-commit当成万能钩子，结果一提交就卡住——因为prettier或eslint --fix扫全量文件，耗时且可能改到不该动的文件。
正确做法是用lint-staged，它只处理git add暂存区里的文件。比如你只改了src/utils.ts，lint-staged就只跑这个文件的prettier和eslint，不会碰node_modules或dist。
-
package.json里配"lint-staged": {"*.{js,ts}": ["eslint --fix", "prettier --write"]} -
husky里pre-commit脚本只调npx lint-staged，别直接调prettier - 如果项目有
gofmt或black，同样按语言后缀配进lint-staged，不要全局扫
VSCode提交面板里看不到模板提示？
不是插件问题，是Git配置没生效。VSCode的提交框本质是调用git commit命令，它是否加载模板，完全取决于本地Git的commit.template设置，跟VSCode设置无关。
常见坑是：在项目根目录放了.gitmessage，但没执行git config commit.template .gitmessage；或者用了--global却指向了错误路径；又或者模板文件编码不是UTF-8，导致中文乱码后VSCode干脆不显示。
- 执行
git config --get commit.template确认路径是否正确 - 模板里用
#开头的行是注释，VSCode会显示但不计入提交内容 - 如果想让所有项目都用统一模板，用
git config --global commit.template ~/.gitmessage，注意~要展开成绝对路径
CI里提交检查失败，本地却过得了
大概率是本地husky没启用，或者钩子脚本权限不对。CI环境默认不执行.husky下的脚本，除非显式安装并启用；而本地开发机上，有人跳过npm install直接git commit，husky根本没注册钩子。
另一个隐蔽问题是Node版本差异：@commitlint/cli在Node 20+下行为可能和CI用的Node 18不一致，比如正则匹配或空格处理逻辑微调，导致同一条提交信息在本地通过、CI报错。
- CI脚本开头加
npm run prepare（如果prepare脚本里含husky install） - 本地验证时，用
git commit --no-verify -m"xxx"绕过钩子，再用echo "xxx" | npx commitlint单独测校验逻辑 - 把
commitlint版本锁死在package.json里，比如"@commitlint/cli": "19.5.0"，避免自动升级引入不兼容变更
commit-msg钩子读取的是git commit传入的临时文件，而pre-commit钩子看到的是暂存区快照——这两者的数据来源和生命周期完全不同，混用判断逻辑必然出错。
