# 1. Keep a Changelog 1.1 的六种变更类型中 Added、Changed、Deprecated、Removed、Fixed、Security A Deprecated 表示新增功能 B Fixed 表示格式调整 C Added 表示移除功能 D Security 用于记录安全相关修复 ✓ 正确答案
# 2. Keep a Changelog 的"Unreleased"段落中当前开发中的变更累积 A 用于累积当前开发中尚未发布的变更 ✓ 正确答案 B 发布后保留 Unreleased 名称不修改 C 用于记录已发布版本的变更 D 只记录安全修复
# 3. Keep a Changelog 的"YANKED"（撤回版本）标记与原因 A 用于标记某个版本虽有缺陷但已发布、应被撤回使用 ✓ 正确答案 B 被撤回的版本应从 CHANGELOG 中删除 C 仅用于 pre-release 版本 D 用于表示版本已成功发布
# 4. Keep a Changelog 的"语义版本对齐"（semantic versioning alignment） A CHANGELOG 与版本号完全无关 B CHANGELOG 分类应与版本号升级类型一致 ✓ 正确答案 C 只有 Fixed 需要递增版本 D CHANGELOG 不能反映破坏性变更
# 5. Keep a Changelog 在 monorepo 的多包协同 A monorepo 只能有一个统一 CHANGELOG B 需要建立"变更→具体包"的映射，才能正确更新各包 CHANGELOG ✓ 正确答案 C monorepo 无需 CHANGELOG D 所有包必须使用相同版本号
# 6. Keep a Changelog 的"升级指南"（Upgrade Guide）章节 A 与 CHANGELOG 功能完全相同 B 只适用于 PATCH 修复 C 用于指导用户迁移到新版本，通常针对 MAJOR 或破坏性变更 ✓ 正确答案 D 升级指南不需要链接到 CHANGELOG
# 7. GitHub Releases 与 GitLab Releases 的发布产物管理 A 两者都基于 git tag，可上传发布产物并关联发布说明 ✓ 正确答案 B GitHub Releases 不支持 pre-release C 两者无法通过 API 自动化创建 D 只能用于源码文件
# 8. npm publish、PyPI upload、Maven Central deploy 的凭据管理 A 凭据可以直接提交到仓库 B 凭据应存储在 CI 平台的密钥管理并在 CI 中注入，绝不硬编码 ✓ 正确答案 C 发布账号应使用最高权限 D 凭据无需轮换
# 9. 包签名（cosign、GPG）与 Sigstore 的发布签名 A Sigstore 通过短暂证书与透明日志实现免密钥的签名与验证 ✓ 正确答案 B Sigstore 必须使用长期 GPG 密钥 C 包签名无法验证产物完整性 D cosign 只能用于 Docker 镜像
# 10. 发布的"原子性"（atomicity）与"幂等性"（idempotency） A 幂等性指重复执行同一发布不会产生不同结果 ✓ 正确答案 B 幂等性指必定产生重复 tag C 原子性指发布可部分成功 D 两者都与可靠性无关
# 11. 发布的"回滚"（rollback）策略中 yank、deprecated、unpublish A yank 将版本标记为撤回但产物仍存在，相比 unpublish 破坏性更小 ✓ 正确答案 B deprecated 会彻底删除版本 C 三种方式效果完全相同 D unpublish 是风险最低的回滚方式
# 12. 版本号与 git tag 的"双向同步"（version ↔ tag）的 CI 强制 A 版本号与 tag 可以随意不一致 B CI 应校验 tag 名与包内版本号一致 ✓ 正确答案 C 一个版本号可对应多个 tag D tag 与版本变更的 commit 无关
# 13. Git tag 的"pre-release"（rc、alpha、beta）的命名约定 A pre-release tag 与正式 tag 无区别 B pre-release 只能使用 alpha 后缀 C 命名通常与 SemVer pre-release 标识对应，如 v1.0.0-rc.1 ✓ 正确答案 D CI 无法区分 pre-release 与正式 tag
# 14. Git tag 的"锁定"（lock）中保护已发布 tag 防止误删 A 已发布 tag 可以随意 force-push B 误删 tag 一定能通过 reflog 找回 C tag 与发布产物无关 D 应通过保护/权限规则限制已发布 tag 的删除与修改 ✓ 正确答案
# 15. 版本号的"deprecation policy"中 API 的 EOL（end of life）周期 A EOL 意味着版本获得更多支持 B deprecation policy 无需提前公布 C EOL 指某个版本不再接收任何修复（包括安全修复）的时间点 ✓ 正确答案 D EOL 只影响 pre-release 版本
# 16. Keep a Changelog 与 GitHub Releases 的发布说明协同 A 应将 CHANGELOG 作为单一事实来源，让 Release 说明复用或由工具同步生成 ✓ 正确答案 B 两者应各自独立手工维护 C 两者内容必须完全无关 D Release 说明无法引用 CHANGELOG
# 17. Keep a Changelog 与 release notes 自动生成工具（towncrier、release-please） A 两者都完全不生成 CHANGELOG B towncrier 依赖变更片段文件，release-please 依赖 Conventional Commits 提交语义 ✓ 正确答案 C towncrier 依赖提交消息而非片段文件 D 两者与 Keep a Changelog 结构不兼容
# 18. 版本号的"停止维护"（EOL）公告与迁移路径 A 应提前公告 EOL 日期并提供明确的迁移路径 ✓ 正确答案 B 迁移路径只需说明升级到最新版即可 C EOL 无需提前通知 D EOL 公告只影响源码
