I2.13.3retry original versus edited设计
重试是否使用原参数还是允许用户修改需求后再试需要明确
别名: 原参数重试 · 改了再试 · retry same request
概念解释
转交之后人要面对一个选择：同一份请求再发一次，还是改了条件再发。这两种重试不是同一按钮。原参数重试覆盖「刚才那一下没送到」；改了再试覆盖「刚才那一下本身就不会成功」——查询写错、文件太大、格式不支持、筛选过窄。界面必须说清这一次将发出去的是哪一种，不能用一颗含混的「重试」同时承担两条语义。
机制
失败原因把参数分成「仍有效」和「已定罪」。超时、502，参数很可能仍有效，再发同一份是对的，改参数是跑题。400、422、格式拒绝，同一份再发只会再拒绝，原参数重试是空转，人需要回到可编辑的需求上。混成一颗按钮时，人无法预测点下去会发生什么：筛选项会不会丢、文件要不要重选、正在写的字会不会被清掉。预测失败会让人不敢点，或点完发现上下文被重置。
明确还保护幂等。原参数重试应带上同一把幂等键，表示「还是那一次」。改了再试是新需求，应换键，否则对端会把新内容当成旧提交的重复而丢掉。语义在界面上分开，键才能分对。
边界
没有可改参数的纯拉列表，只有原参数重试，不必为了对称造一个「修改」。参数很多、失败与参数无关（全站 503）时，把人推去改筛选是在转移责任；应原参数重试，改筛选作为另一次动作。部分成功的批处理（二十个文件五个失败）重试的是失败子集的原参数，还是允许人拿掉两个再试，要在这一批的上下文里说清，默认通常是失败子集原样再来。自动重试永远是原参数，改参数只能发生在转交之后的人手里。
怎么落地
- 瞬态失败：主动作叫「再试一次」，发原请求、原幂等键，不重置表单。
- 参数性失败：主动作是回到可编辑，文案说明哪一项要改；不要提供会再次失败的原样重试当主按钮。
- 两种都说得通时，主按钮原参数，次要动作「修改后重试」，不要合成一颗。
- 验证：一次超时、一次 422。超时的重试应原样发出且表单还在；422 的主动作应让人改字段。若两屏都是同一颗「重试」且 422 再发原 JSON，语义就没分开。