评审分类与专项评审

• 能否用具体事实和复现路径证明 bug 的实际影响
• 能否把"作者认为不需要"转化为"风险可见的决策"
• 能否在必要时升级而不被"作者坚持"带偏

面对"不需要改"，先别急着反驳，而是把 bug 变成可验证的事实：给出复现步骤、影响范围、触发的业务后果。如果作者仍认为不需要，就把"改/不改"变成一次有依据的风险决策，而不是个人争论——说明不改会带来什么代价（用户损失、故障、返工），改的成本是多少。如果确实是"真 bug 但影响小"，可以协商降级为"后续修复项"并记录；如果是"真 bug 且影响大"，作者坚持不改就不能放行，应升级到 leader 或团队例会裁决。核心是"用事实和影响说话"，而不是"你觉得不需要所以不改"。

重大 bug 与"作者觉得不需要"的冲突，本质是"风险判断"的问题。把 bug 的证据链摆清楚，让决策有据可依，才能让作者从"主观觉得"转向"客观判断"。必要时升级，因为 block 级风险不该由个人偏好决定。

• 能否识别 copy-paste 带来的维护与一致性风险
• 能否给出"抽取复用"的改进建议
• 能否理解 copy-paste 的成因（赶时间/不熟悉）并委婉沟通

copy-paste 代码的最大问题不是"重复"本身，而是"维护成本"—同一逻辑被复制多处，改一处时其他处会漏改，导致 bug 不收敛。argue 时先说明：这段代码和已有代码重复，如果后续要改，我们得记着改所有地方，很容易漏。然后建议抽取公共函数/组件/工具，让逻辑单一来源。同时要理解 copy-paste 的成因——可能是赶时间、不熟悉现有代码，所以沟通时可以先去查"现有代码里是否已有类似实现"，用"这段逻辑其实已经存在，我们可以复用"的方式，比"你复制粘贴了"更专业。如果为了速度而复制，也要提醒"现在省的时间，以后会加倍还"。

copy-paste 的核心风险是"维护不一致"和"认知负担"。把问题从"你偷懒"转到"这段逻辑需要单一来源"，同时给出可复用的具体方案，是推动改进的关键。理解成因能让沟通更顺畅。

• 能否准确识别安全反模式及其具体危害
• 能否用"安全风险"的严重后果说服作者
• 能否给出标准的安全修复方案

安全反模式（SQL 注入、明文密码）是必须修复的 blocker 级问题，因为一旦被利用，后果是数据泄露、账户被盗等严重事故。argue 时不能只说"这样不安全"，要具体说明攻击路径和后果：比如"这里把用户输入直接拼进 SQL，只要输入带引号就可能被注入，泄露整个表"。然后给出标准修复方案：SQL 注入用参数化查询/预编译语句，明文密码用不可逆的哈希（如 bcrypt/argon2）加盐存储。如果作者有疑虑，可以用安全漏洞案例或内部安全规范支撑。安全反模式通常没有"不需要改"的余地，应坚持到期修复并升级。

安全问题是质量底线，不能用"内部系统"或"没人攻击"来豁免。用具体攻击场景说明危害，给出标准修复方案，是推动安全修复的关键。安全反模式应作为 blocker 坚决不放行。

• 能否理解"放行+记录"的适用场景与前提
• 能否区分"可放行的非阻塞问题"与"必须拦住的阻塞问题"
• 能否保证"记录"被真正跟踪而非遗忘

"放行但留下 review 记录"适用于"非阻塞但有价值"的问题——比如优化建议、后续改进、可讨论的 nit。它的价值在于：让 PR 不被细节卡住，同时把问题显性化、可追踪。但要预设前提：只有非阻塞问题才适合"放行+记录"，阻塞问题必须改完才能放行。落地时，把"记录"落到可执行的地方——用 PR 的 comment 标注"approve 但以下建议后续跟进"，或建一个 backlog 项，明确 owner 和截止时间，避免"记录"变成"遗忘"。如果只是"为了赶进度而放行"，那就是掩耳盗铃，不可取。

"放行+记录"是平衡"进度"与"质量"的折中机制，前提是问题非阻塞、记录可追踪。它把"暂时不处理"变成"显性待办"，而不是"隐藏问题"。关键是有跟踪、有 owner。

• 能否区分"阻断性"与"建议性"问题
• 能否用"approve + 明确建议"的沟通方式
• 能否让建议被有效跟踪而非被忽略

"可以但建议"是评审的成熟表达：它承认 PR 已满足合并条件（approve），同时把非阻塞的小问题显性化（建议）。表达上要清晰区分：哪些是"必须改"（blocker），哪些是"建议改"（should/nit）。对"建议"部分，可以明确"这几点不影响这次合并，但建议后续处理，比如……"，并给出具体方向。为了让建议不被忽略，可以约定"建议项在 PR 合并后的一周内跟进"或建 backlog。这种表达既尊重作者进度，又体现评审的严谨，比"要么通过要么拒绝"的二元更专业。

"approve + 建议"比"冷冰冰地 approve"或"抓着 nit 不放"更专业。它把建议与阻塞分开，让作者知道"什么必须改、什么是加分项"。关键是建议要具体、可跟踪，避免成为空话。

• 能否把 reject 建立在"阻塞性事实"上而非个人偏好
• 能否给出明确的拒绝理由和修改路径
• 能否在对方坚持时通过升级或仲裁解决

reject 必须建立在"明确的阻塞性事实"上（如 bug、安全、架构缺陷），而不是个人偏好或"我觉得不够好"。argue 时把阻塞理由写清楚：具体问题、为什么不能合并、会带来什么后果、需要改成什么样。如果对方坚持合并，先确认是否双方对同一事实理解不同——如果对方有充分理由（比如"这是临时方案，后续会替换"），可以协商降级或约定替代方案；如果对方只是"急着上线"而忽略阻塞风险，则坚持立场，并升级到 leader 或仲裁。关键是"reject 要有公信力"——理由必须基于事实和风险，而不是姿态。

reject 的底气来自"阻塞性事实"而非个人权威。把理由和修改路径讲清楚，让 reject 是可执行的指导而非"否决"。对方坚持时，用事实、协商、升级三步走，而不是硬碰硬。

• 能否反思"语气"对评审效果的影响
• 能否把"直接"与"建设性"结合
• 能否修复被影响的协作关系

先承认"语气太直接"确实会影响协作，即使内容正确，如果让人不舒服，作者就可能抵触甚至忽略意见。argue 和平衡的方法是：把"意见"和"人"分开，用"对事不对人"的表达——把"你这里写错了"改成"这里有个问题，您看是否考虑……"。同时给意见加"为什么"和"建议"，让直接变成建设性。如果已造成投诉，要主动道歉修复关系，说明本意是保证质量而非针对个人，并调整后续沟通方式。平衡的关键是"直接但尊重"——保留意见的尖锐，去掉对人的攻击性。

评审意见的价值在于"被接受"，语气直接影响接受度。用"对事不对人 + 给理由 + 给建议"的表达，能把"直接"从杀伤变成建设。已造成伤害时，修复关系比坚持"我没错"更重要。

• 能否理解"设计评审"与"实现评审"的不同关注点
• 能否论证分离"先设计后实现"的价值
• 能否设计分离的具体流程

设计评审和实现评审关注点完全不同：设计评审看"方案对不对"（架构、数据模型、接口、非功能需求），实现评审看"代码写得好不好"（正确性、风格、测试、边界）。混在一起的问题是：设计还没定就开始写代码，实现评审时设计又推翻，返工巨大。分离的价值是"先定方向再动手"——设计评审通过后再进入实现，实现只关注代码质量，避免"边写边改设计"。落地方式：设计阶段产出设计文档/ADR，独立评审收敛后再开工；实现阶段用 PR 评审代码。这样每个阶段都有明确的验收标准，返工更少。

设计评审与实现评审分离，是"先 Design 后 Implementation"的工程纪律。它能避免"设计未定就写代码"的返工，让每个阶段职责清晰。设计决定方向，实现决定质量，两者分开才高效。

• 能否识别"不收敛"的成因（目标不清/无决策权/信息缺失）
• 能否用"决策框架"推动收敛
• 能否在必要时升级决策

讨论 3 次不收敛，说明问题不在"讨论不充分"，而在"缺少决策机制"。推动收敛的方法：一是明确"这次评审要决定什么"——把要决策的问题写清楚，避免发散；二是引入"决策框架"——用"成本/风险/收益/时间"做对比，把不同方案变成可比较的选项，而不是各说各话；三是设定"决策截止时间"和"决策人"——不要无限讨论，到点由有决策权的人拍板；四是如果分歧是关键架构决策，可请架构师或 leader 裁决，用"决策记录（ADR）"固化结论。核心是"收敛靠机制，不靠讨论多久"。

评审不收敛到第三轮，往往是缺乏决策机制而非讨论本身。用"明确决策点 + 对比框架 + 截止时间 + 授权决策人"推动收敛，才能把讨论变成决策。升级裁决是负责任的做法，不是失败。

• 能否把"否了但没说哪里"转化为可执行的反馈
• 能否主动澄清而非被动等待
• 能否在澄清时保持尊重、聚焦技术

被否了但没说哪里，最怕的是"否定本身没有信息量"，让人无从下手。主动澄清是第一步：带着具体问题去问，比如"我理解这个方案被否了，为了改进，能帮我明确一下是方向问题（架构/技术选型）还是细节问题（假设/数据模型）吗？"如果 leader 仍说不清，可以把自己的方案拆成几个关键决策点，逐点请对方确认哪一点有问题，把"笼统否定"变成"具体指向"。同时自查：方案是否有明显漏洞？如果确实有，主动补上并重新提交。核心是"用问题把模糊反馈变清晰"，而不是抱怨"你都没说哪错"。

"否了但没说哪里"是低质量反馈，但不能因此卡住。主动用结构化问题澄清领导意图，把笼统否定拆成可执行的具体点，是推动收敛的关键。同时保持尊重，聚焦技术而非情绪。

• 能否认识到"变更不通知"对评审闭环的破坏
• 能否识别哪些变更需要重新评审
• 能否建立"变更通知"的机制

设计评审后变更设计却不通知 reviewer，会让评审失去意义——reviewer 评审的是旧方案，你实现的是新方案，评审结论就成了"过期信息"。这要么导致 reviewer 的意见被浪费，要么导致新方案带了未经验证的风险。argue 时说明：设计变更哪怕是小的，只要影响"评审通过的关键点"，就该通知 reviewer 重新确认。落地方式：变更时在评审线程/文档里 @ 相关 reviewer，说明"基于 XXX 意见，我调整了 XXX，请确认是否符合预期"；如果变更重大，重新走一次相关评审。建立"变更即通知"的约定，是评审闭环的保障。

评审是"结论"而非"一次性动作"，变更后必须通知 reviewer 重新确认，否则结论失效。把"变更即通知"作为约定，才能保证评审始终基于最新方案。这是对评审投入的尊重。

• 能否识别"challenge 是否基于理解"而非一味反驳
• 能否用清晰的解释把对方拉回理解
• 能否从 challenge 中提取有价值的信息

被 challenge 但对方不懂，不能简单当作"他不懂所以别理"。先判断：对方 challenge 的点，是真的有漏洞，还是因为信息不足产生的误解？如果是误解，就把方案的关键背景、约束、取舍讲清楚，用"我在这个场景下做这个选择，是因为……"的方式拉齐理解。同时，即使对方不完全懂，challenge 里也可能藏有值得吸取的视角（比如他提醒的边界 case），要甄别吸收。argue 的核心是"不居高临下、也不敷衍"，认真解释、开放吸纳，同时把讨论拉回"是否理解方案"这个前提上。如果对方确实只是没懂，可以建议评审后单独 1:1 补沟通。

challenge 的价值在于"暴露盲区"，无论对方懂不懂。先拉齐理解，再判断是否有真实问题，既不因"他不懂"而傲慢，也不因"被挑战"而慌乱。对事不对人，甄别吸收。

• 能否区分"破坏性变更"与"兼容性变更"的版本策略
• 能否理解 v2 与 v1.1 的语义差异
• 能否用"变更性质"决断版本策略

API 版本策略取决于"变更是破坏性还是兼容性"：如果只是新增字段、向后兼容，用 v1.1（加小版本）即可，不需要大版本 v2；如果改了字段语义、删字段、改行为（破坏性），才需要 v2 大版本。argue 时先和 reviewer 对齐"这次变更是否破坏现有客户端"。如果兼容，v1.1 更合理——避免逼下游升级，降低迁移成本；如果破坏，v2 才正确——用大版本隔离风险。所以关键不是"谁的决定对"，而是"变更的性质"决定版本策略。可以一起对照语义化版本（SemVer）规范，用它们的标准来裁决。如果双方对"是否破坏"有分歧，就聚焦"下游调用方会不会挂"这个事实。

v1.1 与 v2 的分歧本质是"变更是否破坏兼容"。用 SemVer 语义和"下游是否受影响"作为裁决依据，比主观偏好更可靠。版本策略要服务于"下游兼容"和"风险隔离"。

• 能否理解"原子提交"与"功能提交"的区别
• 能否论证"可回滚、可审查"的 commit 原则
• 能否在两者间达成折中

原子提交（一个 commit 只做一件事）和功能提交（一个 commit 对应一个功能点）并不冲突，只是粒度不同。核心原则是"每个 commit 应可独立理解、可独立回滚"。原子提交的优点是可追溯、好回滚、review 清晰；功能提交的优点是符合逻辑、便于理解整体。argue 时说明：如果"按功能"的 commit 内部混了多件无关的事（比如同时改了两个 bug、夹带了重构），那就不符合原子性，应拆开；如果"按功能"是逻辑内聚的（一个 commit 完成一个自洽的功能），就兼顾了可读性和可回滚。可以协商：采用"功能为单元、commit 内原子"的粒度——每个 commit 对应一个完整功能，但功能内部不混入无关改动。关键是"commit 语义清晰、可回滚"。

commit 粒度之争要落到"可理解、可回滚"原则上。原子性指的是一件事一次提交，功能提交只要逻辑内聚也符合。折中是"功能为单元 + 内部原子"，兼顾可读与可回滚。

• 能否识别"文件组织"与"职责单一"的关系
• 能否用"变更频率、可测试性、团队习惯"论证
• 能否在不伤害质量的前提下达成一致

文件该分还是该合，取决于"职责是否单一"和"可维护性"，而不是"文件数量"本身。reviewer 想分文件，通常是担心职责混杂、单文件过大；你想合并，可能是觉得逻辑内聚、文件少好找。argue 时用具体标准：如果这个文件承担了多个不相关的职责（数据处理、UI、网络），即使再小也该拆；如果是一个逻辑内聚的模块，虽然大但也合理。补充维度：可测试性（拆开是否更易测试）、变更频率（是否经常一起变）、团队代码规范。如果团队有明确规范，按规范来；没有，就协商一个双方能接受的边界。核心是"按职责而非数量"组织代码，必要时用"一个文件内清晰分区"作为折中。

文件分合之争要落到"职责单一 + 可维护性"上，而非文件数量。用职责、可测试性、变更频率作为标准，比"我喜欢多文件/少文件"更客观。折中是"职责分区 + 适度拆分"。

• 能否把选型论证建立在"事实"上（成熟度、维护、社区、性能）
• 能否用"对比评估"替代个人偏好
• 能否在选型后接受团队共识

依赖库选型最容易发生"个人偏好"之争，必须用事实说话。argue 时建立对比维度：功能覆盖、成熟度与维护活跃度、社区规模、性能、学习成本、许可协议、与现有技术栈的契合度。把 A 和 B 在这几个维度逐项对比，用数据（下载量、issues、版本发布频率）支撑。同时考虑团队因素：团队谁更熟、生态是否支持项目需求。如果仍各执一词，可以约定"先做小范围 PoC 验证"再定，或参考内部/业界标准。选型是团队决策，最终要接受共识，一旦确定就按统一的来，避免项目里混用两套库。核心是"用对比矩阵让选型可决策，而不是比谁嗓门大"。

库选型分歧要用"对比矩阵 + 事实数据"化解，从"我喜欢 A"变成"A 在成熟度/性能/生态上优于 B"。PoC 验证和团队共识是最终裁决手段。选型要服务团队长期，而非个人偏好。

• 能否理解两种风格的适用场景（语义/资源 vs 动作/调用）
• 能否用"业务场景 + 团队现有能力"论证
• 能否在风格上保持灵活、在语义上保持一致

RESTful 和 RPC 是两种接口风格，各有适用场景：RESTful 面向"资源"，用 HTTP 方法表达对资源的操作，适合资源模型清晰的 CRUD；RPC 面向"动作/调用"，如 POST /doSomething，适合动作语义明确、非资源对齐的场景。argue 时基于"业务场景"：如果接口本质是资源操作（增删改查用户、订单），RESTful 更契合；如果接口是复杂动作（如"批量结算""触发工作流"），RPC 更直接。还要考虑团队现有能力和客户端习惯。如果双方都讲道理，可以妥协：资源操作走 RESTful，特殊动作走 RPC 风格，在同一体系内共存。核心是"接口语义清晰、一致"，而不是教条地坚持某一种。

RESTful vs RPC 之争要落到"业务场景语义"上，而非风格偏好。资源操作用 REST，动作操作用 RPC，两者可在同一体系内共存。关键是语义清晰、团队一致，而非教条。

• 能否理解"覆盖度"的度量意义与局限
• 能否区分"关键路径 100%"与"无差别 100%"的价值
• 能否用"覆盖的关键程度"而非"数字"论证

覆盖度本身不是终极目标，它衡量的是"哪些代码被测试触达"，而不等于"测试质量高"。100% 覆盖和 80% 覆盖的分歧，关键不在于数字，而在于"覆盖的优先级"。argue 时说明：无差别地追求 100%，可能把时间花在"不容易出错的样板代码"上，而忽略了"高风险的核心逻辑"；更好的策略是"依据风险分配覆盖"——核心业务逻辑、复杂分支、易错边界追求高覆盖，简单、稳定代码可放宽。同时覆盖度不能替代"测试断言的质量"——100% 覆盖但断言很弱，也是假覆盖。可以提议：把"关键路径覆盖"作为硬性要求，整体覆盖度作为参考指标，优先保证高风险代码的覆盖和断言质量。

覆盖度之争要落到"关键路径与风险"上，而非数字高低。100% 无差别追求是低效的，按风险分配覆盖才科学。覆盖度是手段，测试有效性才是目的。

• 能否识别"格式分歧"的本质是缺少统一规范
• 能否用格式化工具终结争论
• 能否在规范选择上保持灵活

4 空格 vs 2 空格这类格式分歧，本质是"没有统一规范"导致的。最专业的做法是：不争论"哪个更好"，而是用工具（formatter）和规范文件（如 .editorconfig、.prettierrc）统一，让格式由工具自动处理，而不是靠人肉约定。argue 时说明：格式分歧浪费在无意义的争论上，用工具 benchmark 一次，团队就永久告别这类争议。如果是团队既有规范，就按规范来；如果还没有，可以推动建立统一规范，并让全团队用同一套 formatter。个人偏好（2 空格还是 4 空格）在统一规范面前不重要——重要的是"一致"。所以核心是"用工具和规范终结格式之争"，而不是证明哪个空格更好。

格式之争是"规范缺失"的症状，不是"哪个空格更好"的问题。用 formatter 和规范文件统一，是终结该类争议的标准解法。一致性比具体偏好更重要。

• 能否识别"分支命名规范"的价值在于一致性与可读性
• 能否用"团队既有约定/工具支持"论证
• 能否在命名上保持灵活、避免无谓争论

分支命名（feature/ vs dev/）本身没有高下之分，价值在于"一致、可读、可被工具识别"。argue 时先看是否有团队既有规范——如果有，按规范来，命名不是个人偏好问题；如果没有，就推动建立一套规范（如 feature/xxx、bugfix/xxx、release/xxx），让命名能表达分支用途。如果双方已各有习惯，可以协商"统一用一种前缀 + 说明用途"，而不是各自为政。核心是"命名要服务于可读性和工具识别"，feature/、dev/ 都行，关键是全体一致。如果团队用 CI 或流程依赖特定前缀，就按流程定的来。命名之争不值得耗费精力，用"团队规范"一锤定音。

分支命名之争的实质是"缺乏统一规范"。按团队既有约定或建立统一规范，比争论哪个前缀好更有价值。命名服务于可读与工具，一致性是关键。

• 能否识别性能反模式及其具体影响（如 N+1 查询）
• 能否用"延迟/资源消耗"的量化说明危害
• 能否给出性能修复方案

性能反模式（如 N+1 查询：先查列表，再对每项查一次数据库）会造成明显的延迟和资源浪费。argue 时不能只说"这是反模式"，要量化影响：比如"这里对 100 条记录每条都查一次库，就是 100 次查询，如果数据量增大，延迟会线性增长，甚至打爆数据库连接"。然后给出修复方案：N+1 用批量查询（join 或 IN 一次取回）、预加载（eager loading）、缓存等。同时提醒性能问题的"放大效应"——现在数据量小看不出，上线后数据量/并发上来就暴露。性能反模式通常可以作为 blocker 或 should 处理，取决于影响的严重程度（是否在核心链路、数据量是否大）。核心是"用量化和放大效应让作者看到风险"。

性能反模式要用"量化影响 + 放大效应"说服，N+1 等问题的危害往往在数据量增大后才显现。给出批量查询、预加载等修复方案，让建议可落地。按影响严重程度确定是否 blocker。

• 能否识别"无限流"在真实环境中的风险
• 能否用"失效场景/成本"反驳"不会有人刷"
• 能否给出轻量可行的限流方案

"不会有人刷"是高估"环境安全"的典型假设。argue 时说明：限流防的不仅是"恶意刷"，还有"异常流量"和"连锁故障"——比如上游 bug 导致大量请求、用户重试风暴、某个接口被误调用，这些都会让服务被打垮。而且加限流成本很低（中间件/网关几行配置），收益是"保护服务可用性"。可以举例：一个接口本应 1 QPS 却支撑 1000 QPS，一次异常就会拖垮数据库。所以"不会有人刷"不成立，因为"刷"不一定是恶意，也可能是意外。建议接入网关/中间件限流，并设置合理阈值。核心是"把被攻击的风险扩展到异常/意外流量"。

无限流的风险不仅来自恶意，更来自异常和意外流量。用低成本限流换取服务可用性，是划算的防御。反驳"不会有人刷"要扩展到"异常流量、连锁故障"场景。

• 能否识别"任意 origin"的 CORS 安全风险
• 能否区分"开发环境"与"生产环境"的配置
• 能否给出环境隔离的修复方案

允许任意 origin 的 CORS，等于允许任意网站的前端脚本跨域访问你的接口，配合已有凭证（cookie/token）就可能造成跨站请求伪造等风险。author 说"开发方便"，argue 时关键是区分"开发环境"和"生产环境"：开发时为了调试放宽 origin 可以理解，但生产环境必须严格限制为可信域名。落地方式：用环境配置区分——开发环境允许本地 origin，生产环境只允许真实的线上域名，并通过 CI 或配置校验保证生产不误用。同时说明风险场景：任意原网站可以发起请求，利用用户已登录的凭证获取数据。核心是"开发方便可以，但生产必须严格，用环境隔离实现两者兼得"。

CORS 任意 origin 的风险是"任意网站可跨域调用"，配合凭证会造成数据泄露。用环境隔离（开发放宽、生产严格）是既方便开发又保证安全的做法。生产默认白名单。

• 能否理解 HttpOnly 的安全作用（防 XSS 窃取 cookie）
• 能否把"不影响功能"与"影响安全"区分
• 能否给出兼容修复方案

不设 HttpOnly，cookie 就能被 JavaScript 读取。一旦页面存在 XSS，攻击者就能用脚本窃取 cookie（尤其是会话 cookie），实现账户劫持。author 说"不影响功能"，argue 时说明：HttpOnly 确实不影响功能（登录、会话照常工作），但它影响的是"安全"——它限制了 JS 读取 cookie，是防御 XSS 的重要屏障。可以反问：如果功能不需要 JS 读 cookie，那设 HttpOnly 没有任何功能损失，还能防窃取，为什么不设？修复很简单：在 Set-Cookie 里加 HttpOnly（以及 Secure、SameSite）。如果确实有 JS 需要读 cookie 的场景，再评估是否必要，但大多数会话 cookie 不需要。核心是"不影响功能 = 不设的理由不成立，因为它零成本提升安全"。

HttpOnly 是零功能成本的安全增益，不设的理由（不影响功能）恰恰不成立。区分"功能"与"安全"，指出加 HttpOnly 没有损失却有收益，是说服的关键。修复成本极低。

• 能否识别"session 过长"的安全风险（会话劫持窗口）
• 能否平衡"用户体验"与"安全"
• 能否给出分级过期策略

session 过期时间过长，意味着会话理论上可以被盗用很长时间（窃取的 cookie 一直有效），安全风险随过期时间线性增加。author 说"用户体验"，argue 时说明：用户体验和安全可以兼得，用"分级过期"策略——比如"活跃会话滑动续期"（用户一直在用就续期，闲置一段时间才过期）既能保证长时间使用的体验，又避免"永久有效"的窗口。同时区分"敏感操作"：普通页面可以宽松，涉及支付、改密等敏感操作要短过期或重新验证。还可以用"绝对过期 + 滑动过期"双机制：绝对过期限制最大时长，滑动过期适应用户活动。核心是"用智能过期替代一刀切的超长过期，兼顾体验与安全"。

session 过长是安全风险，但体验诉求合理。用滑动续期、分级过期、绝对上限等机制，能在不牺牲体验的前提下收紧安全。一刀切的超长过期是最危险的。

• 能否理解 CSRF 的完整防护（token 是其一，还有 SameSite 等）
• 能否指出"只加 token"的局限与正确实现要点
• 能否给出纵深防御方案

"加 token 就行"低估了 CSRF 防护的完整要求。CSRF 防护的 token 方案要正确实现：token 要随机、绑定会话、随每次请求验证、且在请求中不可被第三方读取（配合 SameSite cookie）。如果 token 实现不对（比如空 token、可预测、不校验），等于没防。同时"加 token"不是唯一防线，纵深防御还包括：SameSite cookie（限制跨站携带）、校验 Origin/Referer、敏感操作二次验证。argue 时说明：单一 token 如果实现有漏洞就失效，所以要"正确实现 token + 多层防御"结合。核心是"CSRF 防护要完整、正确、多层"，而不是"有 token 就万事大吉"。

"加 token 就行"忽略了 token 的正确实现和纵深防御。CSRF 防护要 token 正确落地 + SameSite + Origin 校验等多层结合。单一 token 若实现有漏洞，防护即失效。

• 能否反驳"内部系统无风险"的假设
• 能否用"内部数据同样有价值"论证
• 能否给出标准化修复（参数化查询）

"内部用无所谓"是安全管理里最危险的假设。argue 时说明：内部系统同样有数据泄露的风险——内部数据（客户、财务、业务）往往更有价值，且内部系统也可能被外部攻击者通过钓鱼、暴力破解、内网渗透等方式触达。SQL 注入一旦存在，攻击者可能读取/篡改整个数据库，不只是"内部"而已。修复成本很低：用参数化查询/预编译，从源头消除注入。可以反问：参数化查询是标准做法，不额外增加复杂度，为什么不从一开始就用对？"内部系统"不应成为安全降级的理由，安全是底线不分内外。核心是"数据价值不分内外，低成本修复应严格执行"。

"内部系统"不等于"无风险"，内部数据往往更敏感、攻击面更广。参数化查询成本极低却能根除注入，应作为硬性要求。安全底线不应因"内部"而降低。

• 能否理解"前后端职责"与 XSS 防护的边界
• 能否论证"后端输出必须安全"的纵深防御
• 能否指出"依赖前端处理"的漏洞

"前端会处理"把 XSS 防护完全推给前端，这是危险的假设。XSS 的根源是"不可信输入被当作 HTML/JS 执行"，后端是数据的最终出口，如果后端直接输出未转义的用户内容，即使前端做了处理，也可能因为环境差异、接口被直接调用、或前端处理遗漏而仍然触发。argue 时说明：正确的做法是"纵深防御"——前端对展示做转义/编码，后端输出时也要保证安全（对输出做 HTML 编码、设置 CSP、对用户输入做校验）。两者都做，不互相依赖。如果 author 说"前端会处理"，可以反问：如果一个接口被非前端客户端直接调用，前端处理就不生效了，那样怎么办？核心是"后端不能假设前端一定会处理，安全要端到端都有保障"。

XSS 防护不能只依赖前端，因为接口可能被直接调用、前端处理可能遗漏。深度防御要求前后端都做安全输出。把责任完全推给前端会留下漏洞。

• 能否识别"日志中的敏感数据"的泄露风险
• 能否反驳"日志没人看"的假设
• 能否给出脱敏/日志治理方案

"日志没人看"是错误假设——日志恰恰是"会被看"的：运维排障、审计、监控、安全分析都会看日志，而且日志常被备份、同步、外发，泄露面比想象大。如果日志里写了密码、身份证、手机号、token 等敏感数据，任何一个接触日志的人或系统都可能泄露。argue 时说明：日志是"假设敌人会看"的敏感设施，应默认脱敏。落地方式：日志框架里配置脱敏规则（对敏感字段屏蔽/哈希）、不记录敏感字段本身、建立日志审计。核心是"日志默认脱敏，敏感数据不进日志"，而不是"没人看所以没事"。

日志会被运维、审计、监控查看且可能外发，"没人看"的假设不成立。敏感数据进日志是常见泄露点，应默认脱敏、不记录。数据安全不做"没人看"的赌注。

• 能否理解 MD5 用于密码存储的缺陷（快速、可暴力破解）
• 能否给出正确的密码哈希方案（加盐慢哈希）
• 能否反驳"够用了"的假设

MD5 是设计用于校验和的快速哈希，不适合存密码——它速度极快，攻击者可以用 GPU 暴力破解或彩虹表快速还原常见密码，且 MD5 无盐，相同密码哈希相同，可批量破解。author 说"够用了"，argue 时说明：密码存储的标准是"慢哈希 + 随机盐"，如 bcrypt、argon2、scrypt，它们刻意设计得慢，让暴力破解成本极高。MD5 的"快"恰恰是它的致命伤。可以反问：如果攻破数据库，MD5 存的密码等于裸奔，损失的是全部用户。修复不难：改用 bcrypt 等加盐慢哈希，并考虑迁移已有数据。核心是"密码存储不能图快，MD5 是安全反模式"。

MD5 存密码是明确的反模式：快、无盐、可暴力破解。正确做法是加盐慢哈希（bcrypt/argon2/scrypt）。"够用"是低估了攻破后的批量损失，密码安全不容妥协。

• 能否识别"耦合"对可测试性和可维护性的影响
• 能否说明"难测试"的连锁后果
• 能否给出解耦（依赖注入/接口）的具体建议

代码耦合严重（比如一个函数直接 new 依赖、硬编码外部资源）会让它难以测试，因为测试时无法替换依赖。argue 时说明耦合的连锁后果：难测试 → 测试缺失 → 改动时无回归保护 → 出 bug 成本高。这不仅是"测试问题"，更是"可维护性问题"。给出解耦方案：用依赖注入（把依赖传进来而非内部 new）、面向接口（依赖抽象而非具体实现）、拆分职责。然后说明解耦后测试变得容易（可以 mock 依赖），代码也更清晰。argue 时把"耦合"的抽象概念落到"可测试、可维护、可扩展"的具体价值上，而不是讲术语。核心是"耦合是维护和测试的隐患，解耦是长期投资"。

耦合不只影响测试，还影响维护和扩展。用依赖注入、接口隔离解耦，能显著提升可测试性和可维护性。把"难测试"的后果讲清楚，让作者看到解耦的实际价值。

• 能否区分"命名规范"与"个人偏好"
• 能否论证命名对可读性和团队协作的影响
• 能否用规范与工具推动统一

命名是"个人偏好"还是"规范问题"，取决于它是否影响他人理解。好的命名（如 getUserById 而非 getUser / g）直接决定代码可读性，而可读性是团队协作的基础——别人要读、要改、要 review 你的代码。argue 时说明：如果命名含糊到让人误解意图，那就不是个人偏好，而是沟通问题。规范的命名能降低团队整体的认知成本。落地方式：用团队命名规范（如变量/函数/类命名约定）和 lint 工具（如 ESLint 的命名规则）来统一，把"个人偏好"变成"团队一致"。如果团队没有规范，就推动建立，而不是在单个 PR 上争论。核心是"命名规范服务于可读性和团队协作，用规范+工具统一"。

命名影响可读性和团队协作，不能只归为个人偏好。用团队命名规范和 lint 工具统一，是解决命名之争的标准做法。含糊命名会伤害整个团队。

• 能否识别"只测 happy path"的测试盲区
• 能否用"边界/异常导致 bug"的现实论证
• 能否给出具体的测试补全方向

只测 happy path 的测试，等于只在"理想情况"验证，而真实 bug 大多出现在边界和异常：空输入、越界、非法参数、网络失败、重复请求、并发。argue 时说明：测试的价值在于"保护"——如果只测正常路径，一旦有人改了边界处理，测试也测不出来，回归就失效。补全方向：针对每个输入/场景想"正常、边界、异常"三类 case，重点覆盖：空值/非法值、最大/最小值、错误路径（抛出异常）、依赖失败（mock 失败）、多次调用。可以建议用"等价类 + 边界值"方法系统设计测试。核心是"测试要覆盖正常之外的关键路径，否则形同虚设"。

只测 happy path 是测试盲区，bug 多发生在边界和异常。用等价类划分和边界值分析方法补全测试，才能让测试真正起到回归保护作用。happy path 之外才是价值所在。

• 能否识别"意见太多"对作者接受度的冲击
• 能否按优先级分类（blocker/should/nit）
• 能否把"问题数量"转化为"可执行的改进路径"

30 条意见确实会让作者有压力，但"多"不一定错，关键是要"分类"让作者知道优先级。把意见分成三类：blocker（必须改，影响正确性/安全）、should（建议改，影响质量）、nit（可改可不改，风格/小优化）。这样作者能聚焦：先改 blocker，再处理 should，nit 可以协商。同时检查"30 条里是否有重复/同源问题"——如果很多是同类的（比如多处同样的命名问题），可以合并成一条"这类问题建议统一处理"，并给出系统性改法（如用工具批量替换）。argue 时说明：意见多是因为问题客观存在，但会分类呈现，让作者不迷茫。核心是"分类 + 合并同类项，让意见可执行、可消化"。

意见多时分类是关键，blocker/should/nit 让作者知道优先级。合并同类项能减轻"量大"的心理负担。把"30 条"变成"3 个优先级 + 可执行的改进"，是成熟的评审表达。

• 能否识别"单一评审视角"的风险
• 能否论证多样性评审的价值
• 能否设计邀请不同角色的评审机制

设计评审只有 leader 参加，会缺少多样性带来的"盲区消除"价值。不同角色（其他工程师、测试、运维、产品）能提供不同视角：工程师看实现可行性，测试看可测性和边界，运维看部署和可观测性，产品看需求契合。argue 时说明"单一视角"容易漏掉非主角色的关切（比如只从实现角度设计，忽略了运维或测试的难度）。推动方式：按设计的影响范围邀请相关角色——涉及数据/接口的拉前后端，涉及部署的拉运维，涉及用户流程的拉产品；同时营造"评审发言无等级压力"的氛围，让 junior 也敢提意见。核心是"按影响范围组织多样性评审，前置消除盲区"。

单一视角评审会漏掉非主角色的关切。多样性评审按影响范围邀请相关角色，能在设计阶段前置消除盲区。营造无压力的发言氛围，让不同声音被听到。

• 能否识别"无压测上线"的风险（容量未知）
• 能否用"压测成本 vs 事故成本"论证
• 能否给出"低成本快速压测"方案

"先上线观察"把容量风险推给了生产环境，一旦真实流量超过预期，就是线上事故。argue 时说明：压测的价值在于"上线前知道系统能扛多少并发"，避免在上线后才发现扛不住。PM 担心的是压测耗时影响上线，可以给出"低成本快速压测"方案：用线上流量回放或简单压测工具（如 wrk、k6）做一个快速基准，拿到"能承受的 QPS 上限"和"瓶颈在哪"。这句话比"上线观察"更有信息量——上线观察是"等出事才知道"，压测是"提前知道"。如果实在来不及，至少做"上线后监控 + 容量预估 + 快速扩容预案"，把风险兜住。核心是"用压测把未知容量变成已知，至少做好兜底预案"。

无压测上线等于把容量风险交给生产。低成本快速压测能提前知道容量上限和瓶颈，比"上线观察"更有信息量。若不压测，至少要有监控和扩容预案兜底。

• 能否识别"无数据时加机器"的盲目性
• 能否论证"先定位瓶颈再决策"的价值
• 能否给出成本优化的分析路径

没有压测数据就"加机器"，是"用钱解决问题"的盲目做法——可能瓶颈根本不在 CPU/内存，而在 SQL、锁、网络、代码逻辑，加机器解决不了。argue 时说明：先做性能分析（压测 + profiling + 慢查询分析），定位瓶颈在哪，再决定是加机器还是优化代码。如果瓶颈是"单点 SQL 慢"，加机器没用，要优化查询；如果瓶颈是"横向扩展确实不足"，加机器才对。同时给数据：加机器是持续成本，优化代码是一次性投入，两者要权衡。可以建议"先花 1-2 天做压测定位，再决定"，避免盲目横向扩容。核心是"用数据定位瓶颈，让加机器成为有依据的决策而非拍脑袋"。

无数据加机器是盲目扩容，可能投入了钱却解决不了瓶颈。先压测/分析定位瓶颈，再用数据决定"加机器还是优化代码"，才是按根因决策。加机器是持续成本，优化是一次性投入。

• 能否识别"内部网络"上的明文传输风险
• 能否反驳"内部网络绝对安全"的假设
• 能否给出低成本的 HTTPS 方案

"内部网络没事"是常见误解。内网同样可能被窃听（网络嗅探、中间人攻击、被攻破的跳板机），而且明文传输的密码、会话、业务数据在传输过程中等于裸奔。argue 时说明：HTTPS 现在几乎是零成本（Let's Encrypt 免费证书、内部 CA、网关统一 TLS），配置一次全网生效，没必要为"内部"省掉。可以反问：如果内网真有机器被攻破，那这台机器能嗅探到所有明文流量，这个风险有多大？安全性应该"默认加密"，而不是"默认信任网络"。落地方式：在网关/负载均衡统一启用 TLS，应用层无需大改。核心是"默认加密，不赌内网安全"。

内网同样存在窃听和中间人风险，明文传输是隐患。HTTPS 成本已极低，应默认启用。安全性默认不信任网络，而非默认信任内网。网关统一 TLS 是低成本方案。