I3.02.3no optimistic irreversible设计
不可逆操作不适用乐观更新
别名: 不可逆乐观 · 支付乐观 · 发送不可撤 · irreversible write
概念解释
一旦真实世界的后果收不回来——钱划走、邮件离开发件箱、账号删掉、法律文件提交——就不能先在屏幕上假装已经发生。不可逆操作不适用乐观更新：界面必须等到权威侧确认，再把状态画成完成。乐观靠的是「错了还能收回」；不可逆把这张保险单作废。
「不可逆」指对用户有意义的后果不可收回，不是数据库能不能 undo。一封已经出现在对方收件箱里的信，本地再怎么回滚都晚了。
机制
乐观更新的安全垫是对称的回滚：服务器说不，屏幕把像素倒回去，真实世界没有被改过，债务清零。不可逆操作打破对称。请求一旦被对端接受，后果落在别的系统、别的人、或一条不能改写的记录上。此时屏幕若早已画成成功，分叉窗口里的人会继续往下走：关掉对话框、告诉对方「我发了」、离开支付页。等失败（或更糟：成功但不是用户以为的那一笔）回来，能收回的只有像素，收不回已经发生的外部效应。
第二层是确认的时机。不可逆动作通常需要最后一次意图确认（金额、收件人、删除范围）。把完成态提前画出来，等于把确认从「权威结果」偷换成「本地猜测」，确认仪式还在，约束已经空了。支付类还叠加了重复提交风险：乐观成功让人以为可以离开，超时后又重试，对端可能已经扣过一次。
边界
「发送」若产品承诺在对方读之前可撤回，撤回窗口内可以乐观展示「已发出」，但必须标成仍可收回，不能画成对方已读。软删除进回收站是可逆的，乐观可以；过了保留期的彻底清除不行。本地加密、本地录音这类从未离开设备的操作，失败面是磁盘而不是对端，不算这条里的不可逆。多人会立刻看见的发布（动态、公告）对发布者是不可逆的社交后果，即使技术上能删，也常应按不可逆来等确认。法规要求双人复核或签字的流程，乐观会直接跳过法定时序。
怎么落地
- 列出所有不可逆写入：支付、对外发送、永久删除、权限授予到组织外、法律提交。这些路径禁止在确认前把主状态画成完成。
- 按下之后立刻给本地的「已接受、正在提交」——这是即时因果，不是乐观成功。完成态只在权威应答之后出现。
- 超时不要改画成成功。停在「仍在提交 / 未知」并给出查询或联系入口，直到权威侧有结论。
- 验证：在支付、发信、永久删除上注入 5 秒延迟再成功，以及注入失败。若延迟期间界面已经出现「已支付 / 已发送 / 已删除」，这条违规。失败时若曾闪过完成态，同样违规。对照一条可逆操作（点赞）：允许先亮，用来确认乐观没有被误杀到整个产品。