I3.02.2explicit rollback disclosure设计
失败回滚必须显式告知
别名: 回滚提示 · 静默撤销 · silent revert · 乐观失败
概念解释
乐观写入被服务器拒绝，界面把刚才画上去的成功拿掉——这是回滚。显式告知指拿掉的同时必须让人知道「刚才那次没写成」，而不是像素自己缩回去、像从未发生。静默回滚是第二种谎言：第一次谎称成功，第二次谎称无事。
这条要的是失败被当作事件发出。提示里写什么原因、能不能重试、界面要不要擦得一点痕迹不留，是回滚机制的细节，不是这里的判定。这里的判定只有一句：人必须能回答「刚才那一下到底成了没有」。
机制
乐观窗口里，人已经把屏幕当真实。关闭窗口有两种做法。一种发事件：「没发出去」。事件把模型从「已完成」改写成「未完成」，后续决策可以停。另一种不发事件，只把像素倒回。倒回在变化盲视和眼不在场时很容易被漏掉；即便看见「亮的心灭了」，也缺少「为什么灭」的因果，人会当成自己误触再点一次，或当成界面自己抽风。
更糟的是归因倒置。静默回滚之后，列表里那条评论没了，人去检查是不是自己删了、是不是刷新丢了。错误被编进用户侧，服务器拒绝（权限、配额、审核）从未进入意识。下一次同样的操作会再失败，因为真正的障碍没有被放进模型。
边界
瞬时、可逆、无后续的微反馈（按错键的涟漪、拖到非法区的回弹）回弹本身就是告知，不必再弹一条横幅。但只要乐观结果已经被拿去当下一步的输入——「已加购」后去结算、「已发送」后离开对话——回滚就必须开口。失败若发生在用户已经离开这条屏幕之后，告知要追到人还在的通道（通知、回来后的条），不能只在原位点闪一下。批量乐观里一条失败、九条成功，只把失败那条缩回去而不说，人会以为十条都成了。
怎么落地
- 每一次乐观失败都发出可感知事件：就近的错误、列表项上的失败态、或回来后还能读到的一条说明。禁止只把像素倒回。
- 事件至少要让人完成这句填空：「刚才的 X 没有成功」。
- 用户已离开原屏幕时，把同一句话送到他们还在看的通道，不要等他们碰巧翻回来。
- 验证：断网或让接口失败，乐观点一次赞、发一条评论、改一项设置。录下回滚的三秒。若画面回到失败前、期间没有任何「没成功」的证据，判定失败。再请一位没盯着该控件的人看回放，问「刚才成了没有」——答不上来就是静默回滚。