# 1. 你 review 别人的 PR 发现一个重大 bug 但 PR 作者说"不需要改"，你怎么看怎么 argue A 尊重作者，他比你看得懂 B 在群里当众揭穿作者 C 直接合并，反正作者不认 D 用复现路径和影响证据摆清风险，把是否修改变成有依据的决策 ✓ 正确答案
# 2. 你 review 别人的 PR 发现是 copy-paste 的代码，你看怎么 argue A 直接批评作者偷懒 B 指出重复带来的维护风险，建议抽取复用，理解成因委婉沟通 ✓ 正确答案 C 接受复制，反正能跑 D 强制要求作者重写全部代码
# 3. 你 review 别人的 PR 发现是有"安全反模式"（SQL 注入/明文密码），你看怎么 argue A 既然是内部系统，可以接受 B 先合并，以后再说 C 让作者自己决定，不管 D 说明具体攻击路径和后果，用参数化查询等标准方案修复，作为 blocker 不放行 ✓ 正确答案
# 4. 你 review 别人的 PR 想"放行但留下 review 记录"，你怎么看怎么 argue A 适用于非阻塞问题，且记录要有 owner 和跟踪，避免变成遗忘 ✓ 正确答案 B 所有问题都可以放行+记录 C 记录就是不管，直接合并 D 放行+记录等于放弃评审
# 5. 你 review 别人的 PR 想 approve 但有些小问题，你看怎么 argue "可以但建议" A approve 并明确区分"必须改"与"建议改"，建议给出具体方向并跟踪 ✓ 正确答案 B 不 approve，等所有问题都改完 C 直接 approve，什么都不说 D 把建议写得像 blocker，逼作者改
# 6. 你 review 别人的 PR 想 reject 但对方坚持合并，你看怎么 argue A 对方坚持就让他合，别起冲突 B 直接合并，不 maintain 立场 C 用强硬语气强迫对方接受 D 基于阻塞性事实说明理由和修改路径，必要时升级或仲裁 ✓ 正确答案
# 7. 你 review 别人的 PR 时语气太直接，PR 作者投诉，你看怎么 argue 平衡 A 坚持我没错，是他太敏感 B 反过来投诉他 C 以后再也不提意见，避免冲突 D 调整表达为"对事不对人"，给理由和建议，主动修复协作关系 ✓ 正确答案
# 8. 你的团队设计评审和实现评审混在一起（先设计评审再实现），你怎么看怎么 argue 分离 A 先做设计评审收敛方案，再进入实现评审，两阶段分开 ✓ 正确答案 B 一起评审，一次性搞定 C 只做实现评审，不评设计 D 只做设计评审，实现靠自觉
# 9. 你的设计评审意见不收敛（来回讨论 3 次还没结论），你怎么看怎么推动收敛 A 继续讨论，直到大家都同意 B 放弃评审，让作者自己定 C 明确决策点、用对比框架、设截止时间和授权决策人，必要时升级裁决 ✓ 正确答案 D 谁的嗓门大听谁的
# 10. 你的设计评审文档被 leader 否了但没说哪里，你看怎么 argue A 主动带着具体问题澄清，把方案拆成关键决策点逐点确认哪有问题 ✓ 正确答案 B 等 leader 主动说明白 C 直接改一版模板重新提交 D 认为 leader 故意刁难
# 11. 你的设计评审后变更设计但没通知 reviewer，你怎么看怎么 argue A 没关系，改就改了 B 只会让 reviewer 更忙 C reviewer 会更开心 D 评审结论过期失效，新方案带了未经验证的风险 ✓ 正确答案
# 12. 你的设计评审被同事 challenge 但他不懂，你看怎么 argue A 因为他不懂，直接无视 B 当场反驳，证明他错 C 先讲清背景和取舍拉齐理解，再甄别 challenge 中是否有价值点 ✓ 正确答案 D 让 leader 把他赶出评审
# 13. 你和 reviewer 对 API 版本管理有分歧（他要 v2，你要 v1.1），你怎么看怎么 argue A 依据变更是否破坏兼容：兼容用 v1.1，破坏性才用 v2 ✓ 正确答案 B 谁资历深听谁的 C 永远用 v2，越大越好 D 永远用 v1.1，避免升级
# 14. 你和 reviewer 对 commit 粒度有分歧（他要原子，你要按功能），你怎么看怎么 argue A 原子提交一定正确，功能提交一定错 B commit 粒度无所谓 C 一个 commit 越少越好 D 采用"功能为单元、内部原子、可独立回滚"的粒度，兼顾可读与可追溯 ✓ 正确答案
# 15. 你和 reviewer 对代码组织有分歧（他要分多个文件，你要合并），你怎么看怎么 argue A 依据职责是否单一、可测试性、变更频率和团队规范 ✓ 正确答案 B 文件越少越好 C 文件越多越好 D 看 reviewer 心情
# 16. 你和 reviewer 对依赖库选型有分歧（他要 A，你要 B），你怎么看怎么 argue A 用对比矩阵（成熟度/性能/生态/团队熟悉度）论证，必要时 PoC 验证 ✓ 正确答案 B 谁的偏好强听谁的 C 永远选新库 D 永远选老库
# 17. 你和 reviewer 对接口设计有分歧（他要 restful，你要 rpc），你怎么看怎么 argue A RESTful 永远正确 B RPC 永远正确 C 依据业务场景：资源操作用 REST，动作操作用 RPC，保持语义一致 ✓ 正确答案 D 随便是哪种，能通就行
# 18. 你和 reviewer 对测试覆盖度有分歧（他要 100%你要 80%），你怎么看怎么 argue A 覆盖度越高越好，必须 100% B 只要数字到了就行 C 覆盖度不重要，有测试就行 D 依据风险分配覆盖，核心逻辑高覆盖，同时重视断言质量而非数字 ✓ 正确答案
# 19. 你和 reviewer 对代码格式化有分歧（他要 4 空格，你要 2 空格），你怎么看怎么 argue A 坚持自己习惯的空格数 B 谁先写谁定 C 让每个文件用不同空格数 D 用 formatter 和规范文件统一，让格式由工具保证一致性 ✓ 正确答案
# 20. 你和 reviewer 对分支命名有分歧（他要 feature/，你要 dev/），你怎么看怎么 argue A 按团队既有规范或建立统一命名规范，保持一致性 ✓ 正确答案 B 坚持自己的前缀 C 每个分支随机命名 D 命名不重要，随便写
# 21. 你 review 别人的 PR 发现是有"性能反模式"（N+1 查询等），你看怎么 argue A 量化查询次数和延迟成本，说明放大效应，给出批量查询/预加载方案 ✓ 正确答案 B 只是慢一点，没关系 C 让作者自己优化 D 先合并再优化
# 22. 你的项目 API 没做限流，author 说"不会有人刷"，你怎么看怎么 argue A 说明限流防的是异常/意外流量和连锁故障，低成本高收益，应接入 ✓ 正确答案 B 同意，别浪费资源 C 告诉他必须限流，否则开除 D 不管，刷了再说
# 23. 你的项目 CORS 配置错了（任意 origin），author 说"开发方便"，你怎么看怎么 argue A 开发环境放宽、生产环境严格白名单，用环境配置隔离 ✓ 正确答案 B 同意，开发方便最重要 C 生产也允许任意 origin，反正方便 D 禁止所有跨域
# 24. 你的项目 cookie 没设 HttpOnly，author 说"不影响功能"，你怎么看怎么 argue A 确实不影响功能，可以接受 B 设 HttpOnly 会导致功能崩溃 C HttpOnly 零功能成本却防 XSS 窃取 cookie，应加上 ✓ 正确答案 D 无所谓，XSS 很少见
# 25. 你的项目 session 过期时间太长，author 说"用户体验"，你怎么看怎么 argue A 为了体验，session 越长越好 B 不设过期，永远有效 C session 越短越好，哪怕一直掉线 D 用滑动续期+绝对上限+敏感操作分级，兼顾体验与安全 ✓ 正确答案
# 26. 你的项目有 CSRF 风险但 author 说"加 token 就行"，你怎么看怎么 argue A 对，加 token 就安全了 B 加 token 没用，别浪费时间 C token 要正确实现并配合 SameSite、Origin 校验等多层防御 ✓ 正确答案 D 只要有一个 token 就行
# 27. 你的项目有 SQL 注入风险但 author 说"内部用无所谓"，你怎么看怎么 argue A 内部系统确实没风险 B 内部系统出问题没人管 C 内部数据更有价值，注入风险不分内外，应用参数化查询根治 ✓ 正确答案 D 别管注入，内部随便
# 28. 你的项目有 XSS 风险但 author 说"前端会处理"，你怎么看怎么 argue A 对，交给前端就行 B XSS 只在特殊场景存在 C 后端不用管 XSS D 应前后端纵深防御，后端输出也要安全，不能依赖前端处理 ✓ 正确答案
# 29. 你的项目有敏感数据未脱敏（日志里），author 说"日志没人看"，你怎么看怎么 argue A 确实没人看，无所谓 B 日志会被排障/审计/监控查看且可能外发，应默认脱敏 ✓ 正确答案 C 日志里写什么都行 D 只在生产脱敏，其他不管
# 30. 你的项目涉及密码存储但用的 MD5，PR author 说"够用了"，你怎么看怎么 argue A 够用就用，别折腾 B MD5 是最安全的 C MD5 快且无盐易破解，应改用加盐慢哈希（bcrypt/argon2） ✓ 正确答案 D 密码加密了就行，什么算法都行
# 31. 你 review 别人的 PR 发现代码耦合严重（难测试），你看怎么 argue A 用依赖注入和接口隔离解耦，提升可测试性和可维护性 ✓ 正确答案 B 能跑就行，测试不重要 C 写更复杂的测试去适配 D 不写测试，避免麻烦
# 32. 你 review 别人的 PR 发现命名不规范但 PR 作者说"个人偏好"，你怎么看怎么 argue A 用团队命名规范和 lint 工具统一，强调命名影响可读性和协作 ✓ 正确答案 B 尊重个人偏好，不管 C 强制改名，没有商量 D 命名不重要，能读就行
# 33. 你 review 别人的 PR 发现测试只覆盖 happy path 不看怎么 argue 补全 A happy path 够了，也测不出更多 B 只测主流程，其他靠运气 C 测试数量越多越好，不分场景 D 用等价类/边界值方法补全边界、异常、错误路径等关键场景 ✓ 正确答案
# 34. 你 review 别人的 PR 提了 30 条意见，PR 作者说"太多了"，你看怎么分类 A 减少意见数量，只提最重要的 B 删掉所有意见，只 approve C 按 blocker/should/nit 分类并合并同类项，让意见可执行 ✓ 正确答案 D 坚持全列，作者自己消化
# 35. 你的设计评审只有 leader 参加，缺少多样性，你怎么看怎么推动 A leader 最懂，够了 B 只邀请 senior，junior 别来 C 每个评审都拉所有人，人多力量大 D 按设计影响范围邀请相关角色（前后端/测试/运维/产品），消除盲区 ✓ 正确答案
# 36. 你的项目上线前没做压测，PM 说"先上线观察"，你怎么看怎么 argue A 好，先上线看情况 B 上线后出了问题再说 C 压测太慢，直接上 D 用低成本快速压测提前知道容量上限，或至少做好监控和扩容预案 ✓ 正确答案
# 37. 你的项目上线后性能差但没压测数据，leader 说"加机器"，你怎么看怎么 argue A 听 leader，先加机器 B 加机器最省事 C 先压测定位瓶颈，用数据决定加机器还是优化代码 ✓ 正确答案 D 性能差就换语言
# 38. 你的项目用了 HTTP（不是 HTTPS），leader 说"内部网络没事"，你怎么看怎么 argue A 内网确实安全 B 只有公网才需要 HTTPS C 内网用 HTTP 是国际惯例 D 内网也有窃听风险，HTTPS 成本已低，应默认加密 ✓ 正确答案
