部分失败时保留已完成成果
别名: 部分成功 · partial success · 批量操作容错
概念解释
一次操作如果包含多个子任务（批量删除五十个文件、给一百人发通知、导入一份含多条记录的表格），其中几个子任务失败时，系统应该保留已经成功完成的那部分成果，只把失败的部分单独报告出来，而不是把整个操作当成一次失败、要求用户从头重新做一遍。这看似是个小细节，实际决定了用户为一次局部失误付出的代价是"重新处理三条失败记录"还是"重新处理全部一百条记录"，差距可以是几十倍。
机制
把"部分失败"当成"整体失败"处理，通常是因为借用了数据库事务里"要么全部成功、要么全部回滚"的思路——这个思路在保证底层数据一致性时是对的，但直接套用到面向用户的多步操作上就会造成不必要的浪费：用户面对的不是一条需要保持内部一致的记录，而是一批彼此独立、成功与否互不影响的子任务，其中三条记录导入失败，不代表另外九十七条也必须作废。保留已完成成果需要系统在执行过程中就把每个子任务的结果单独记录下来，而不是等全部跑完才统一判断整体成功还是失败，这样才有能力在出现部分失败时精确地只重跑失败的那部分。
边界
这条原则适用于子任务之间确实互相独立的批量操作，如果子任务之间存在真实的依赖关系或必须保持整体一致（比如一笔转账里的扣款和入账必须同时成功或同时失败），强行保留部分成果反而会破坏数据的正确性，这种场景仍然需要底层事务保证的全有全无语义，不能套用这条原则。判断的关键是子任务之间有没有真实的耦合，而不是操作在界面上看起来是不是"一批"。
怎么落地
对任何允许用户一次性提交多个子任务的界面，执行完成后分别报告成功和失败的子任务清单，失败清单要给出具体原因（权限不足、格式错误、目标已不存在），并只对失败的部分提供重试入口，不要求用户重新选择或重新填写已经成功的部分。如果子任务之间存在真实依赖，明确告知用户这次操作是全有全无的，不要用同一套界面语言去呈现两种完全不同的失败语义。验证办法：在测试环境里让一次批量操作里若干比例的子任务人为失败，检查用户完成剩余修复所需的操作步骤数——如果步骤数和从零开始重做整批操作相当，说明部分成果没有被真正保留，只是换了一种方式重新暴露给用户。