conventional commits规范要求header严格匹配type(scope): subject格式，type须小写且为预定义值，scope可选但需英文括号包裹，subject首字母小写、结尾无句号、长度≤50字符，冒号后必须空格；自动化工具依赖此结构解析。
Git 提交信息不是写给机器看的，但规范的格式能让机器自动解析、生成 ChangeLog、过滤提交、识别破坏性变更——前提是人先写对。
conventional commit 的 header 格式必须严格匹配 type(scope): subject
这是所有自动化工具（比如 conventional-changelog、semantic-release）能工作的前提。不满足这个结构，脚本就无法提取 type 或判断是否为 feat / fix。
-
type必须是小写，且仅限预定义值：常见有feat、fix、docs、style、refactor、perf、test、build、chore；自定义类型需团队统一约定并同步到工具配置中 -
scope是可选的，但一旦使用，必须用英文括号包裹，多个 scope 用逗号分隔，如feat(auth,api): ...；不要写成feat(auth, api):（空格非法）或feat[auth]:（方括号不识别） -
subject开头字母小写，结尾不加句号；长度建议 ≤50 字符；冒号后必须跟一个空格，feat(api):add user是错的，feat(api): add user才对
commit-msg hook 拦截不合规提交时，错误常来自正则误配或空格处理
很多团队用 husky + commit-msg 钩子校验格式，但本地提交仍能绕过，往往是因为正则没覆盖空格、换行或中文标点。
- 典型错误正则：
^feat|fix|docs|...—— 缺少锚定和完整匹配，会把xxx feat: yyy也当成合法 - 正确写法应类似：
^(feat|fix|docs|...)(\([^)]*\))?: [a-z].*，注意开头^、结尾$、空格和小写字母约束 - 如果项目允许中文
subject，正则里不能硬写[a-z]，而要用[^\n]或更宽松的字符集，否则中文提交直接被拒 - 钩子脚本里读取 commit message 时，别直接用
cat $1，要head -n1 $1只取第一行 header，否则 body 或 footer 里的内容会干扰匹配
用 git cz 替代 git commit 时，cz-config 必须与团队规范对齐
git cz 不是开箱即用的“自动规范”，它只是把填空题搬到了终端里。填什么、怎么填，全由 .cz-config.js 或 cz-conventional-changelog 版本决定。
- 默认
cz-conventional-changelog@3.x对应 Angular 规范，type 列表较老（不含perf），若团队用perf，需升级到@4.x或手动 patchtypes配置 - scope 提示文案默认是 “scope (optional)”，但团队若强制要求所有提交带 scope（如按模块名
user、order），就得改questions配置，把 scope 设为 required 并提供下拉选项 - 如果项目用 Monorepo，不同 package 有不同 scope 约束，
cz默认不支持动态 scope 列表，得配合cz-customizable或写自定义 adapter
ChangeLog 自动生成失败，大概率卡在 footer 解析或版本前缀上
conventional-changelog 工具链依赖 commit footer 中的 Closes #123 或 BREAKING CHANGE:，但这些字段对格式极其敏感。
-
BREAKING CHANGE:必须独占一行，且冒号后要有空格；写成BREAKING CHANGE:旧接口已移除会被忽略，必须是BREAKING CHANGE: 旧接口已移除 -
Closes #123、Fixes #456等关键词必须出现在 footer 区域（header 和 body 之后、最后一个空行之下），写在 body 里无效 - 生成 ChangeLog 时若指定
--release-count 0却没输出，检查最近一次 tag 是否符合v1.2.3格式；用git tag看到的是1.2.3或release/1.2.3，工具就无法识别为语义化版本起点
最常被跳过的细节是：header 行末不能有多余空格，footer 的关键词必须顶格写，以及所有工具（cz / husky / conventional-changelog）的版本必须协同升级——差一个小版本，type 列表或解析逻辑就可能对不上。
