# 1. 大型 PR 的拆分策略中按功能垂直切片、按层水平拆分、按风险分阶段提交 A 大型 PR 无法拆分，只能整体提交 B 拆分只会增加冲突 C 三种策略互斥，只能选一种 D 按功能垂直切片、按层水平拆分、按风险分阶段提交，目标是每个 PR 可独立合并验证 ✓ 正确答案
# 2. 大型 PR 的评审技巧中先审接口契约 → 再审核心逻辑 → 最后审细节；利用 PR 描述与评审提纲引导 A 先审接口契约→核心逻辑→细节，并用 PR 描述/提纲引导评审重点 ✓ 正确答案 B 大型 PR 应从第一行逐行审到结尾 C 细节最优先，应最先审 D 评审提纲会限制评审自由
# 3. 大型变更的"设计评审前置"中在编码前完成架构与设计评审，避免 PR 阶段发现根本性设计问题 A 设计问题在编码后评审也不迟 B 前置评审会拖慢开发，应取消 C 编码前评审架构与设计，避免 PR 阶段发现根本性设计问题导致大面积返工 ✓ 正确答案 D 设计评审与 PR 评审重复
# 4. 大型 PR 的依赖拓扑评审中如何按依赖顺序分批评审（先契约与数据模型 → 再核心逻辑 → 最后接入层），使每一批变更都可独立合并验证？ A 依赖顺序无关紧要，可任意合并 B 先合接入层最合理 C 按"契约→核心逻辑→接入层"依赖顺序分批，每批可独立合并验证回滚 ✓ 正确答案 D 分批评审无法独立验证
# 5. 大型 PR 的增量评审中利用 GitHub 的 "Changes since last review" 功能聚焦增量变更 A 每次评审都应重读整个 PR 全部内容 B 该功能只能用于小型 PR C 增量评审会漏掉已审部分 D 增量评审只聚焦上次评审后的新增变更，降低认知负荷，分轮次覆盖大型 PR ✓ 正确答案
# 6. 大型 PR 的评审者分工中不同评审者关注不同方面（安全、性能、业务逻辑） A 所有评审者都应看所有方面 B 分工只用于安全评审 C 分工会导致漏审 D 按安全/性能/业务等专长分工，让各评审者深入其领域，提升覆盖深度与效率 ✓ 正确答案
# 7. 大型 PR 的评审时间管理中分多次评审、设定单次评审时间上限 A 应一次审完大 PR，避免中断 B 评审时间越长质量越高 C 分多次评审并设定单次时间上限，避免疲劳导致漏检 ✓ 正确答案 D 设定上限会降低质量
# 8. 大型 PR 的拆分策略中按提交/按文件/按功能拆分的取舍与工具支持？ A 按文件拆分最利于评审，应优先 B 按功能拆分逻辑完整、按提交可回溯、按文件简单但易碎片化，通常以功能为主配合提交 ✓ 正确答案 C 三种拆分单元完全等价 D 拆分单元不影响评审质量
# 9. 超大型 PR 的评审降载中焦点评审、AI 预审与分级评审如何组合？ A 大型 PR 只能放弃评审 B 分级评审会降低高风险部分的质量 C 降载意味着所有部分都快速略过 D AI 预审降噪、焦点与分级评审聚焦关键风险部分，组合让超大型 PR 可审且关键受控 ✓ 正确答案
# 10. 大型 PR 的自动化检查中 CI 全覆盖？ A 大型 PR 只需跑构建，无需测试 B CI 全覆盖（构建/测试/静态分析/覆盖率/扫描等）为大型变更提供自动化兜底，人工聚焦语义 ✓ 正确答案 C CI 全覆盖会降低人工评审价值 D CI 只覆盖增量部分即可
# 11. 大型 PR 的变更度量门禁中 diff 行数、文件数、圈复杂度增量超过阈值时的强制拆分规则如何设定，并让 CI 自动阻断超限 PR？ A PR 大小无需约束，随意提交 B CI 无法自动化阻断 PR C 阈值越高越好，永远不阻断 D 设定 diff/文件数/复杂度阈值，超限由 CI 自动阻断并引导拆分，防止巨型 PR ✓ 正确答案
# 12. 大型 PR 的"评审预算"中如何按文件风险与变更影响分配 reviewer 注意力，避免平均用力？ A 评审应平均分配注意力到每个文件 B 所有文件都需最深评审 C 按文件风险与变更影响分配注意力，高风险深审、低风险快审，避免平均用力 ✓ 正确答案 D 低风险文件也应深审
# 13. 减少评审面中将无关重构（重命名、格式化、依赖升级）拆为独立 PR，如何让核心功能 diff 最小化？ A 无关重构应混入核心功能 PR，一并提交 B 混入重构能减少提交次数，应提倡 C 把重命名/格式化/依赖升级等无关变更拆为独立 PR，让核心功能 diff 最小化 ✓ 正确答案 D 评审面与评审质量无关
# 14. stale review 治理中作者推送新提交后已批准部分如何复核，如何防止"批准后继续塞变更"？ A 批准后无论如何修改都无需复核 B 批准后作者可以随意修改 C 新提交自动重置批准，评审者复核增量，门禁要求批准覆盖最新提交，防止批准后塞变更 ✓ 正确答案 D stale review 无法治理
# 15. "巨型 PR 即技术债"中如何推动团队限制 PR 规模并度量改善？ A 巨型 PR 评审难、易漏检，是技术债，应通过规范+门禁限制并度量改善 ✓ 正确答案 B 巨型 PR 是高效交付，不是技术债 C 巨型 PR 无需度量 D 限制规模会降低开发效率
# 16. 大 PR 的回滚风险与保护？ A 大 PR 出问题只能整体重来，无保护手段 B 通过 feature flag 支持关闭、小粒度拆分、可逆性设计与合并策略保障，降低回滚风险 ✓ 正确答案 C 大 PR 不存在回滚风险 D 回滚保护只用于数据迁移
# 17. 大型 PR 的文档与沟通中变更说明？ A 大型 PR 无需变更说明，代码自解释 B 沟通是多余的 C 变更说明只在出问题后才写 D 变更说明（动机/方案/风险/测试/评审重点）与主动沟通降低理解成本，支撑大型 PR 评审 ✓ 正确答案
# 18. 大型 PR 的合并策略中 squash、rebase 与 merge commit 对历史可读性、回滚粒度与追溯的影响？ A squash 历史干净但回滚粒度粗、merge commit 保留完整历史利于追溯与精细回滚，需权衡取舍 ✓ 正确答案 B 三种合并策略对历史的影响完全相同 C rebase 会丢失所有历史 D merge commit 历史最干净
