版本发布前处理遗留缺陷，关键是把“能不能延期”从口头判断变成有依据、有记录的发布决议。延期处理的前提是缺陷已被明确记录、评估过影响并取得发布决策人的书面同意。可按影响范围可控、无数据或安全风险、有可接受的临时规避手段、触发条件与回修时间已确定四条判断；涉及核心交易链路、数据一致性、安全合规、无法规避且高频触发的缺陷，应作为发布阻断项处理，不进入延期清单。
要点总览（TL;DR）
- 延期处理的前提是缺陷已被记录、评估过影响并取得发布决策人确认；判断时按影响范围可控、无数据与安全风险、有可接受的临时规避手段、回修时间与触发条件明确四条同时成立来筛选。
- 核心交易链路中断、数据丢失或错乱、安全合规风险、无法规避且高频触发的缺陷属于发布阻断项，不进入延期清单；阻断项需关闭或由发布决策人单独给出处置结论并留痕。
- 处理流程分五步：汇总候选缺陷、逐条影响评估、多方评审形成结论、登记回修版本与责任人、发布决策人确认并留痕，每步都有明确的输入与完成标志。
- 测试、研发、产品、业务方分别提供事实、方案、影响判断与规避验证，发布决策人签署放行结论；任何一方交付物缺失，该条延期结论视为未完成。
- 发布前按检查清单核对影响评估、回修信息、阻断项处置、放行留痕与后续跟踪，全部通过再执行发布。
先定判断口径：哪些遗留缺陷可以延期
对单条遗留缺陷做放行或阻断判断时，建议按固定顺序走：先判断它是否属于发布阻断项，再判断是否满足延期条件，最后确定延期需要哪些补偿动作。顺序固定下来，评审时就不容易因为讨论角度不同而得出相反结论。
四条延期判断条件
一条缺陷要进入延期清单，以下四条需要同时成立，缺一条就应回到阻断或继续修复的讨论中。
- 影响范围可控：缺陷只影响特定入口、特定角色或特定配置下的少数用户，主流程和大多数用户不受影响。判断时要写清影响模块、触发条件和受影响用户范围，避免用“影响不大”这类无法核对的描述。
- 无数据与安全风险：缺陷不会造成数据丢失、数据错乱、越权访问、敏感信息泄露，也不违反合同或合规要求。存在这类风险时，临时规避手段也无法把风险降到可接受水平。
- 存在可接受的临时规避手段：用户或运营方可以通过明确的操作绕开问题，例如关闭某个非核心开关、改用另一条入口、由客服提供标准话术。规避手段要在真实场景中验证过，并写清由谁执行、对用户如何说明。
- 回修时间与触发条件明确：已经确定在哪个后续版本修复、由谁负责、用什么方式验证修复结果。仅有“下个版本修”的口头承诺不够，需要落到具体版本号和责任人。
发布阻断项清单
以下情形应作为阻断项处理，不进入延期清单：
- 核心交易链路中断，用户无法完成下单、支付、登录等关键动作；
- 造成数据丢失、数据错乱或跨用户数据串读；
- 存在安全漏洞、权限越权或合规风险；
- 问题无法规避，且在目标用户中高频触发；
- 临时规避手段本身需要用户承担明显成本，或会引发新的误解与投诉。
阻断项并不意味着版本一定不能发布，而是必须先关闭，或由发布决策人针对该条缺陷单独给出处置结论并留痕，不能混在普通延期项里一并放行。
操作步骤：从缺陷清单到延期决议
判断标准确定后，需要一条固定的处理流程，把散落在各处的遗留缺陷收敛成一份可签署的延期决议。下面五步给出每步的输入、动作、输出和完成标志。
第一步：汇总候选遗留缺陷
输入是当前版本所有未关闭缺陷。动作是筛选出计划随版本发布而遗留的缺陷，并补齐严重程度、影响模块、复现条件、发现阶段、当前状态等字段。输出是一份字段完整的候选清单。完成标志是清单中不存在严重程度或影响模块缺失的条目，否则先补录再进入评估。
第二步：逐条做影响评估
输入是候选清单。动作是由测试和研发对每条缺陷标注影响范围、用户可见程度、是否存在规避手段、规避手段的验证结果。输出是每条缺陷的影响评估结论。完成标志是每条缺陷都有明确的“有/无规避手段”结论，且规避手段经过实际验证而非推测。
第三步：多方评审形成结论
输入是带评估结论的缺陷清单。动作是由产品、研发、测试、业务方共同评审，逐条给出“延期”或“阻断”结论，并对结论有分歧的条目当场讨论到形成一致意见。输出是一份带结论的评审记录。完成标志是所有候选缺陷都有明确结论，没有“待定”条目带入发布决策环节。
第四步：登记延期补偿信息
输入是判定为延期的缺陷。动作是为每条缺陷登记回修版本、责任人、验证方式和临时规避说明。输出是延期缺陷台账。完成标志是每条延期缺陷的回修版本和责任人都不为空，验证方式可被执行。
第五步：发布决策人确认并留痕
输入是评审记录与延期台账。动作是由发布决策人逐条确认，签署放行结论，明确本次发布携带的残余风险。输出是发布放行记录。完成标志是放行记录可追溯到具体缺陷条目、评审参与人和确认时间。
在这条流程中，延期缺陷的登记、回修版本关联和评审结论留痕需要有承载位置。ONES 的缺陷工作项可以记录严重程度、影响模块、状态与关联版本，评审结论和回修安排随缺陷一起保留，后续版本复盘时能直接查到当时为什么放行、约定在哪个版本修复。
角色分工与各自交付物
延期评审容易流于口头同意，常见原因是角色职责不清、没人对材料负责。下表把每个角色在评审中的职责和需要交出的材料对应起来，评审时按表核对即可。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| 测试负责人 | 说明缺陷的实际表现与影响范围 | 缺陷影响范围说明、复现步骤与证据 |
| 研发负责人 | 评估修复成本，给出规避方案与回修排期 | 修复工作量判断、规避方案、回修版本与责任人 |
| 产品负责人 | 判断业务影响与用户可接受度 | 业务影响结论、是否接受残余风险的意见 |
| 业务或运营方 | 确认临时规避手段在真实场景中可行 | 规避手段验证结果、用户沟通口径 |
| 发布决策人 | 签署放行结论，对残余风险负责 | 发布放行记录与确认留痕 |
职责边界上，测试负责人提供事实，研发负责人提供方案与排期，产品负责人和业务方提供影响判断，发布决策人做最终取舍。任何一方缺席，相应交付物就缺失，该条缺陷的延期结论应视为未完成。
示例：一次发布前的延期评审
以下为演示情景，用于说明判断标准与流程如何落地，不指向具体产品或真实项目。
某版本计划周五发布，发布前遗留缺陷清单中有四条待处理：
- 缺陷A：某报表页面在筛选条件为空时展示异常，主流程不受影响，用户可先选择筛选条件再查询；
- 缺陷B：订单支付回调偶发重复通知，可能导致重复记账；
- 缺陷C：某后台管理页面的排序按钮在特定浏览器下无响应，运营方可改用另一浏览器操作；
- 缺陷D：用户头像上传后偶发不显示，重新上传可恢复，发生频率较低。
按判断口径逐条处理：缺陷B涉及数据一致性，属于阻断项，必须修复后再发布，不进入延期清单。缺陷A、C、D影响范围可控、无数据与安全风险、存在已验证的规避手段，且回修版本可以确定，判定为可延期。
对三条可延期缺陷登记补偿信息：缺陷A约定在下个迭代版本修复，责任人为对应前端开发，验证方式为筛选条件为空时页面正常展示；缺陷C约定随下个补丁版本修复，责任人为对应前端开发，验证方式为在目标浏览器中完成排序操作；缺陷D约定在下个迭代版本修复，责任人为上传模块开发，验证方式为连续上传多次确认头像正常显示。三条缺陷的临时规避说明分别写入客服话术和运营操作指引。
评审记录按“缺陷编号—结论—影响说明—规避手段—回修版本—责任人—验证方式”的格式呈现，末尾附发布决策人的放行结论与确认时间。这样一份记录既是本次发布的放行依据，也是后续版本核对回修情况的输入。
完成检查：延期决议是否站得住
发布前按以下清单逐项核对，全部通过再执行发布。任何一项不通过，回到对应环节补齐后再确认。
| 检查项 | 通过标准 |
|---|---|
| 影响评估与规避说明 | 每条延期缺陷都有影响范围说明和经过验证的规避手段，无空白项 |
| 回修信息登记 | 每条延期缺陷都有回修版本、责任人和可执行的验证方式 |
| 阻断项处置 | 阻断项全部关闭，或已由发布决策人单独给出处置结论并留痕 |
| 放行结论留痕 | 放行结论经发布决策人确认，记录可追溯到缺陷条目、参与人和时间 |
| 后续跟踪 | 延期缺陷已进入后续版本的跟踪范围，回修完成后有验证记录 |
这份清单的价值在于把“大家都同意”变成“每条都有据可查”。发布后若延期缺陷在线上被触发，团队可以直接调出当时的评估与规避说明，判断是评估偏差还是执行问题，为下一次发布评审提供改进依据。
常见问题
如果某条缺陷影响范围很小，但修复成本很高，可以直接延期吗？
影响范围小只是四条延期条件中的一条，还需要同时确认无数据与安全风险、存在经过验证的临时规避手段、回修版本与责任人已确定。修复成本高可以作为排期讨论的输入，但不能替代其余三条判断。若该缺陷涉及数据一致性或安全合规，即使影响范围小，也应按阻断项处理。
发布决策人不在评审现场，能否先发布后补签放行结论？
不建议这样做。放行结论是延期决议成立的前提，缺少确认的延期缺陷在流程上仍属于未完成状态。如果发布决策人确实无法到场，可以提前把评审记录和延期台账发给他，由其书面确认后再执行发布；事后补签会让记录时间与实际发布顺序不一致，后续复盘时难以判断当时的决策依据。
临时规避手段由客服或运营执行，评审时需要验证到什么程度？
规避手段需要在真实场景中验证过，而不只是方案描述。评审时至少应确认：执行规避操作的角色清楚具体步骤，操作后用户侧表现符合预期，用户沟通口径已经准备好。可以由业务或运营方在测试环境或预发环境实际操作一遍，把验证结果写入评审记录，避免上线后才发现规避手段不可行。
延期缺陷在后续版本修复后，还需要做哪些收尾动作？
回修完成后需要按登记的验证方式执行验证，并把验证结果记录到对应缺陷上，确认缺陷关闭。同时核对当时约定的回修版本是否与实际修复版本一致，若发生版本调整，应在记录中说明原因。这样下一次发布评审时，团队能查到每条延期缺陷从放行到关闭的完整过程。
多条缺陷指向同一模块时，能否合并成一条延期决议？
可以合并评审，但建议保留逐条记录。同一模块的多条缺陷可能影响范围、规避手段和回修排期各不相同，合并成一条会让回修版本和验证方式变得模糊。实际操作中可以在评审记录里按模块分组呈现，每条缺陷仍保留独立的结论、规避说明和回修信息，便于后续逐条验证关闭。
