# 1. Conventional Commits 1.0.0 的结构中<type>[optional scope]: <description> A type 是可选字段，description 才是必填的 B `feat` 和 `fix` 是唯一会直接影响 SemVer 版本号的类型 ✓ 正确答案 C scope 用方括号包裹并紧跟 type 之后 D description 必须使用大写字母开头
# 2. Conventional Commits 的 BREAKING CHANGE 标记中! 后缀或正文 footer A 必须在 body 中写 BREAKING CHANGE footer，`!` 无效 B `!` 后缀和 footer 中的 BREAKING CHANGE 都会触发 MAJOR 版本升级 ✓ 正确答案 C `!` 后缀只能用在 body 中，不能用在 header D BREAKING CHANGE 只影响 PATCH 版本号
# 3. Conventional Commits 的 release-please、semantic-release 自动化生成 CHANGELOG A release-please 直接发布到 npm，不经过 PR 审核 B 两者都通过解析提交历史中的 feat/fix/BREAKING CHANGE 来推算版本号 ✓ 正确答案 C semantic-release 从不生成 CHANGELOG D 两者都依赖人工手动填写版本号
# 4. Conventional Commits 的 commitlint 配置（@commitlint/config-conventional） A @commitlint/config-conventional 只能用于前端项目 B commitlint 通过 extends 配置引入 @commitlint/config-conventional 规则集 ✓ 正确答案 C commitlint 无法校验 header 长度 D commitlint 会在 push 时自动生成 CHANGELOG
# 5. Conventional Commits 与 git message 的 lint（commitlint、commitizen）协同 A commitizen 负责校验，commitlint 负责引导书写 B commitizen 引导书写规范消息，commitlint 在提交时校验拦截 ✓ 正确答案 C 两者功能完全相同，可任选其一 D commitizen 用于生成 CHANGELOG
# 6. Conventional Commits 与 squash merge 的协同 A squash merge 会跳过 Conventional Commits 校验 B squash merge 后每次提交都保留在历史中 C squash merge 后所有提交被合并，PR 标题成为提交消息 ✓ 正确答案 D 使用 squash merge 就不需要配置 commitlint
# 7. Conventional Commits 在 git hook（commit-msg）的强制门禁 A commit-msg hook 在 push 时执行 B commit-msg hook 只能校验代码格式 C commit-msg hook 在提交落盘前执行，校验失败会阻止提交 ✓ 正确答案 D commit-msg hook 无法访问提交消息文件
# 8. Conventional Commits 的"type"语义边界中 feat vs fix、refactor vs perf A refactor 会触发 MAJOR 版本升级 B feat 和 fix 都会触发版本号升级，feat 触发 MINOR、fix 触发 PATCH ✓ 正确答案 C fix 触发 MINOR 版本升级 D perf 与 refactor 语义完全相同
# 9. SemVer 2.0.0 的三段式版本中 MAJOR.MINOR.PATCH 的语义定义 A MAJOR 在不兼容 API 变更时递增 ✓ 正确答案 B MINOR 在缺陷修复时递增 C PATCH 在功能新增时递增 D 版本号不反映兼容性
# 10. SemVer 与"hyrum's law"（海拉姆定律）的张力 A Hyrum's Law 说明 SemVer 完全准确 B Hyrum's Law 只影响 PATCH 版本 C Hyrum's Law 说明用户可能依赖未文档化的行为，使 SemVer 的兼容性承诺难以完全兑现 ✓ 正确答案 D Hyrum's Law 与 SemVer 无关
# 11. SemVer 的 0.x.y 语义中初始开发期的不稳定性 A 0.x.y 阶段公共 API 不稳定，任何变更都可能破坏兼容性 ✓ 正确答案 B 0.x.y 中 MAJOR 会递增 C 0.x.y 阶段保证完全向后兼容 D 0.x.y 与 1.x.y 语义完全相同
# 12. SemVer 的 MAJOR 升级条件中不向后兼容的 API 变更 A 任何代码改动都需要递增 MAJOR B 只新增功能就需要递增 MAJOR C MAJOR 与兼容性无关 D 删除或重命名公共 API 属于不兼容变更，应递增 MAJOR ✓ 正确答案
# 13. SemVer 的 MINOR 升级条件中向后兼容的功能新增 A 任何破坏性变更都递增 MINOR B 修复缺陷时递增 MINOR C 以向后兼容方式新增功能时递增 MINOR ✓ 正确答案 D MINOR 递增不影响 PATCH
# 14. SemVer 的 PATCH 升级条件中向后兼容的 bug 修复 A 新增功能时递增 PATCH B PATCH 递增会改变 MAJOR C 任何修改都递增 PATCH D 向后兼容的缺陷修复时递增 PATCH ✓ 正确答案
# 15. SemVer 的先行版本（pre-release）中 1.0.0-alpha、1.0.0-rc.1 的语义 A pre-release 版本优先级高于正式版本 B 1.0.0-rc.1 与 1.0.0 优先级相同 C pre-release 版本优先级低于对应正式版本 ✓ 正确答案 D 依赖方在 ^1.0.0 下会自动获取 pre-release
# 16. SemVer 与 calendar versioning（CalVer）中 Ubuntu、Chrome 的取舍 A CalVer 强调兼容性语义，SemVer 强调时间 B 两者语义完全相同 C Ubuntu 使用 SemVer D SemVer 强调兼容性语义，CalVer 强调时间可读性 ✓ 正确答案
# 17. SemVer 的 Cargo 版本约束中^1.2.3、~1.2.3、1.2.* 的差异 A ^1.2.3 允许 < 2.0.0 的所有版本 B Cargo.toml 中写 1.2.3 默认等价于 ^1.2.3 ✓ 正确答案 C ~1.2.3 允许 < 2.0.0 的所有版本 D 1.2.* 允许 < 2.0.0 的所有版本
# 18. Conventional Commits 与 Gitmoji 的取舍 A Gitmoji 是官方规定的标准格式 B 两者完全等价 C Gitmoji 表达灵活但难以被标准工具解析，Conventional Commits 更利于自动化 ✓ 正确答案 D Conventional Commits 不能用于自动化
# 19. Conventional Commits 的 type 自定义扩展（warning、security、deps） A 任何自定义 type 都会触发 MAJOR 升级 B 自定义 type 默认不触发版本号升级，除非显式配置 ✓ 正确答案 C 规范禁止自定义 type D 自定义 type 无需在 commitlint 中配置
# 20. SemVer 的 npm 版本范围中^、~、>=、<、1.2.x 的工程语义 A ^1.2.3 允许 >= 1.2.3 且 < 3.0.0 B ~1.2.3 允许 >= 1.2.3 且 < 2.0.0 C 1.2.x 允许 >= 1.2.0 且 < 2.0.0 D ^0.2.3 允许 >= 0.2.3 且 < 0.3.0 ✓ 正确答案
# 21. SemVer 的"deprecation"（弃用）周期中标记 → 警告 → 移除 A 弃用后立即移除且不递增版本 B 先标记弃用、再警告、最后移除，移除时递增 MAJOR ✓ 正确答案 C 弃用只影响 PATCH D 弃用无需用户感知
