# 1. 大变更的"分阶段"（phased）拆分中 Strangler Fig（绞杀者）与 Branch by Abstraction 的协同 A Branch by Abstraction 建立抽象契约，Strangler Fig 提供逐步替换节奏，二者协同让大变更分阶段可回滚 ✓ 正确答案 B 两者互斥，只能选其一 C 分阶段只适用于旧系统，新功能不可分 D 大变更必须一次性切换，无法分阶段
# 2. 大变更的"功能开关"（feature flag）驱动中发布 ≠ 上线 A 功能开关把发布与上线解耦，允许提前部署、按节奏灰度、出问题一键关闭回退 ✓ 正确答案 B 发布与上线必须同时，代码部署即生效 C 功能开关只能用于前端 D 开关一旦开启就不能关闭
# 3. 大变更的"影子流量"（shadow traffic）测试中生产流量拷贝到新系统 A 影子流量把真实请求直接发给用户的新系统 B 影子流量复制生产请求到新系统但不影响用户，通过对比响应验证新系统正确性 ✓ 正确答案 C 影子流量只用于性能测试 D 影子流量会中断线上服务
# 4. 大变更的"接口契约"（interface contract）演进中版本化、Adapter、Facade A 契约可以随意破坏，调用方自行适配 B 版本化是唯一合法手段 C 契约演进只能一次性全部替换 D 通过版本化、Adapter、Facade 提供兼容层，让调用方平滑迁移、渐进演进 ✓ 正确答案
# 5. 大变更的「可观测性先行」中迁移前如何建立新旧系统对比指标体系（对账、错误率、延迟差、数据一致性），支撑灰度放量与回滚决策？ A 迁移完成后才需要建立指标 B 迁移前建立对账、错误率、延迟差、数据一致性等对比指标，作为灰度放量与回滚依据 ✓ 正确答案 C 指标只用于事后复盘 D 灰度决策无需指标支持
# 6. 大变更（big bang change）的反模式与风险中 Knight Capital 因发布脚本误部署在 45 分钟内损失约 4.4 亿美元的事故教训？ A big bang 变更高效无风险，应推广 B 大爆炸式变更失败面大、难回滚，Knight Capital 事故警示必须拆解、分阶段、可观测、可回滚 ✓ 正确答案 C 大爆炸变更只对金融公司有风险 D 事故教训是不要用脚本发布
# 7. 大变更的"PR 拆分"（PR split）中按层、按特性、按风险 A 按层、特性、风险拆分，使每个 PR 可独立合并、验证、回滚 ✓ 正确答案 B 大变更应合并成一个超大 PR，便于整体评审 C 拆分会让合并顺序混乱，应避免 D 拆分只适用于前端项目
# 8. 大变更的"指标灰度"（metric-based）中错误率、延迟指标触发回滚 A 灰度放量无需监控，直接全量 B 回滚只能人工手动执行 C 指标只用于性能优化 D 指标灰度逐步放量，错误率/延迟等指标超阈值即触发回滚或停止放量 ✓ 正确答案
# 9. 大变更的拆解中如何分成可审的小 PR？ A 拆解就是把文件按行数平均分块 B 拆解只对代码风格有意义 C 拆解会增加合并冲突，应整体提交 D 按功能切片、依赖顺序与关注点分离拆解，使每个 PR 独立可编译、可测试、可合并 ✓ 正确答案
# 10. 大变更的文档中设计说明与迁移计划？ A 设计说明记录方案与取舍，迁移计划给出分阶段步骤与回滚预案，支撑评审与执行 ✓ 正确答案 B 大变更无需文档，直接写代码 C 文档只在完成后补写 D 文档只用于向管理层汇报
# 11. 不可简单回滚的数据迁移如何设计可逆方案，双写、回放、切换开关与对账的配合，以及回滚后如何恢复双写状态？ A 数据迁移必然不可逆，无法规避风险 B 通过双写、回放、切换开关与对账设计可逆方案，回滚时先切读、停写、补数据并恢复双写 ✓ 正确答案 C 数据迁移只需直接切换，无需方案 D 回滚时数据一定丢失
# 12. 大变更的干系人与变更窗口中发布窗口、回滚预案与跨团队沟通如何纳入分阶段计划？ A 大变更只需自己团队执行，无需跨团队 B 回滚预案只在出事后才需要 C 变更窗口随时可发，无需选择 D 明确干系人、选择发布窗口、准备回滚预案并跨团队沟通，纳入分阶段计划 ✓ 正确答案
# 13. 大变更的灰度试点选择中如何挑选低风险、高验证价值的业务先行切换，再逐步扩展范围？ A 选择低风险、高验证价值的业务先行，验证通过再逐步扩展范围 ✓ 正确答案 B 应直接选择核心业务做试点，验证最充分 C 试点与扩展无关，直接全量 D 试点只用于验证性能
# 14. 大变更的"流量灰度"（traffic split）中按 header、cookie、IP A 流量灰度只能按比例随机切分，无法定向 B 灰度切分无需稳定，用户可随机切换版本 C 可按 header/cookie/IP 维度切分，实现稳定路由与定向灰度、逐步放量 ✓ 正确答案 D 流量灰度只用于 A/B 实验
# 15. 分阶段审查的节奏中里程碑与合并策略？ A 分阶段审查无需里程碑，直接合并 B 以里程碑划分阶段，按"契约→核心逻辑→接入层"顺序合并，每阶段过门禁再放行 ✓ 正确答案 C 每个阶段可跳过验证直接合并 D 合并顺序无关紧要
# 16. 大重构的评审中如何降低风险？ A 重构无需测试，直接改 B 重构风险与普通功能相同 C 重构评审重点验证行为等价性，配合测试、影子流量与小步拆分降低风险 ✓ 正确答案 D 重构只能全量重写，无法小步
# 17. 大 PR 的文档中变更说明与决策记录？ A 大 PR 无需文档，代码自解释 B 变更说明与决策记录（ADR）让评审者快速理解动机与取舍，提升评审效率 ✓ 正确答案 C 文档只在评审完成后补写 D 决策记录只用于向领导汇报
# 18. 分阶段合并中 feature flag 与渐进发布？ A 合并即上线，无法分离 B feature flag 只用于停止开发中的功能 C feature flag 让代码可提前合并（默认关闭），与渐进发布结合实现"合并≠上线"的分阶段发布 ✓ 正确答案 D 渐进发布无需开关支持
# 19. 分阶段迁移的阶段门禁中每阶段的完成定义与放行标准如何制定，防止半成品状态长期滞留？ A 每个阶段定义完成标准与放行条件，防止半成品长期滞留，保证迁移可控 ✓ 正确答案 B 阶段门禁会拖慢迁移，应取消 C 阶段可以无限期停留，无需处理 D 门禁只适用于数据迁移
