装 Conventional Commits（作者：vivaxy）插件，开箱即用、实时提示、提交前校验首行格式，不依赖 CLI；scope 必须小写，不可用 PascalCase；仅拦截 VSCode 内提交，终端 git commit -m 不受控。
VSCode里装哪个插件能自动校验Conventional Commits格式
直接装 Conventional Commits（作者：vivaxy）这个插件，它不依赖外部 CLI，开箱即用，且支持实时输入提示和提交前校验。
别选名字带“gitmoji”或“commitizen”的插件——它们要么只管 emoji、要么必须配 CLI 工具链，反而在 VSCode 里增加配置负担。
- 安装后重启 VSCode，新建提交时输入
git commit或用 Source Control 面板点提交按钮，编辑框会自动弹出格式提示 - 插件默认识别
feat、fix、chore等类型，也支持自定义，在设置里搜conventionalCommits.types改 JSON 数组 - 如果提交信息没按格式写（比如缺冒号、空格错位），保存时会标红并提示错误位置，不是等 push 才报错
提交时提示“scope must be lower case”，但我的模块名是 PascalCase 怎么办
Conventional Commits 规范明确要求 scope 必须小写，这是校验器强制项，不是插件 bug。PascalCase 的模块名（如 UserProfile）不能直接当 scope 用。
- 把 scope 换成语义化的小写标识，比如
user-profile、auth、api-client，而不是源码目录名的直译 - scope 不是路径映射，而是逻辑边界。改
src/components/UserProfile→ scope 用components更合理 - 如果团队已有约定（如统一用
ui表示所有组件相关变更），就沿用，别强行对齐文件夹名
为什么用了插件，git commit -m 还是能绕过校验
插件只拦截 VSCode 内部的提交流程（比如 Source Control 面板点击提交、或调用 Git: Commit 命令），对终端里手动执行的 git commit -m 完全无感。
- 想全局拦截，得配 Husky + commitlint，插件只是辅助，不是守门员
- 插件的
conventionalCommits.enforceOnCommit设置为true后，仅对 VSCode 提交生效；它不会重写git命令行为 - 日常开发建议关掉终端手敲
-m，养成用 VSCode 提交面板的习惯，否则插件形同虚设
commitizen 和 VSCode 插件能一起用吗
能，但没必要。两者目标重叠，混用反而容易冲突——比如 commitizen 的 cz-conventional-changelog 会覆盖 VSCode 插件的提示逻辑，还可能因 Node 版本不一致导致交互卡死。
- 如果项目已用 commitizen，就停用 VSCode 的 Conventional Commits 插件，统一走 CLI 流程
- 如果只是个人开发或小团队，优先用插件，省去全局安装
commitizen和配置.czrc的麻烦 - 注意：插件不生成 CHANGELOG，commitizen 也不生成——这俩都只是提交格式工具，别指望它们替代
standard-version或semantic-release
最常被忽略的一点：插件默认不校验正文（body）和页脚（footer）是否符合规范，比如 BREAKING CHANGE: 是否顶格、是否带空行。这些得靠 commitlint 配合 Husky 补全，VSCode 插件只管第一行。
