中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。

中文 Git 提交规范 1. Conventional Commits 中文适配基于 Conventional Commits 1.0.0 规范，针对中文团队的实际使用习惯进行适配。类型（type）定义类型说明示例场景 feat 新功能添加用户注册模块 fix 修复缺陷修复登录页白屏问题 docs 文档变更更新 API 接口文档 style 代码格式（不影响逻辑）调整缩进、补充分号 refactor 重构（非新功能、非修复）拆分过长的服务类 perf 性能优化优化首页列表查询速度 test 测试相关补充用户模块单元测试 chore 构建/工具/依赖变更升级 webpack 到 v5 ci 持续集成配置修改 GitHub Actions 流程 revert 回滚提交回滚 v2.1.0 的登录重构原则 type 保留英文关键字（工具链兼容性好） scope 和 description 使用中文 body 使用中文完整描述 2. 中文 commit message 模板完整示例 3. Subject 行规范格式规则 type : 必填，从上方类型表中选取 scope : 选填，表示影响范围，使用中文模块名示例：用户模块、订单、支付、基础组件 description : 必填，中文简述，不超过 50 个字符使用动宾短语：「添加 xxx」「修复 xxx」「优化 xxx」不加句号结尾不要写「修改了代码」这种无意义描述好的示例反面示例 4. Body 编写规范 Body 用于详细说明本次变更的动机、方案和影响。编写要点说明为什么要做这个改动（背景/原因）说明怎么做的（技术方案摘要）说明影响范围（哪些模块、接口受影响）每行不超过 72 个字符（中文约 36 个汉字）正文与标题之间空一行 Body 模板 5. Breaking Changes 标注当提交包含不兼容变更时，必须在 footer 中标注。格式一：footer 标注格式二：type 后加感叹号团队约定涉及数据库表结构变更必须标注 BREAKING CHANGE 涉及公共 API 参数/返回值变更必须标注涉及配置文件格式变更必须标注标注时须写明迁移方法或升级步骤 6. Issue 关联 GitHub 格式 Gitee 格式 Coding 格式通用写法 7. Changelog 自动生成配置安装 conventional changelog package.json 脚本 .versionrc.js 中文配置 8. commitlint 中文配置安装 commitlint.config.js 9. husky + lint staged 集成安装与初始化配置 commit msg 钩子配置 pre commit 钩子 lint staged 配置（package.json）交互式提交（可选）运行 npm run commit 即可进入交互式提交引导。 10. 团队规范检查清单提交前自查 [ ] type 是否正确选择（feat/fix/docs/...） [ ] scope 是否准确描述了影响模块 [ ] subject 是否为动宾短语且不超过 50 字符 [ ] subject 末尾是否去掉了句号 [ ] body 是否说明了变更原因和方案 [ ] 不兼容变更是否标注了 BREAKING CHANGE [ ] 相关 Issue 是否已关联 [ ] 一次提交是否只做了一件事（原子性）团队落地步骤 1. 工具链配置：按上述步骤配置 commitlint + husky，让规范可执行 2. 模板共享：将 .commitlintrc 、 .husky/ 等配置提交到仓库 3. 团队培训：组织 15 分钟的规范说明会，演示工具使用 4. Code Review ：Review 时关注 commit message 质量 5. 持续迭代：每季度回顾规范执行情况，根据团队反馈调整常见问题 Q: 中英文混排时空格怎么处理？ A: 中文与英文/数字之间加一个空格，如「添加 Redis 缓存」。 Q: scope 用中文还是英文？ A: 团队内统一即可。推荐中文（可读性好），但需在 commitlint 中关闭 scope case 检查。 Q: 多人协作时如何保证规范一致？ A: 靠工具而非靠自觉。配置好 husky + commitlint，不符合规范的提交会被拦截。