E1.17.4optimistic unlock desync设计研究
乐观更新场景下按钮解锁时机与结果反馈时机可能不同步
别名: 乐观更新解锁 · 先成功后失败 · optimistic UI button
概念解释
乐观更新（optimistic update）在服务器确认前就把界面写成成功：点赞立刻亮、评论立刻出现。这时按钮常被立刻解锁，好让人继续下一条。服务器稍后拒绝，界面要回滚，但按钮已经像空闲。解锁时机与结果反馈时机不同步：人以为这件事结束了，其实还在赌网络。再点一次会叠出第二条乐观记录，回滚时更乱。
机制
乐观路径把「输入已接收」和「结果已产生」压成同一帧。按钮若按「界面已经变了」来解锁，锁的是用户感知的结束，不是事务的结束。真结果晚到且为失败时，回滚发生在用户已经离开这条、甚至已经基于成功做了下一步（关对话框、刷下一页）。若乐观成功后仍保持锁到服务器确认，又会把乐观的轻快感抵消，人会连点——而连点在乐观模型里每下都生成一条本地记录。同步问题不是要不要乐观，是锁应对准哪一个时刻：防双发仍要在发出时锁极短一下，防「未确认当结束」则要在未确认期间留下未决标记，而不是把按钮装成完全空闲。
怎么研究
做点赞/发评论的乐观界面，操纵确认延迟和失败率。记录解锁时刻、成功外观出现时刻、失败回滚时刻，以及其间用户是否又点。
自变量：解锁对齐界面变化还是对齐服务器确认、失败是否回滚、未决标记是否可见。 因变量：重复乐观记录、回滚后的困惑报告、基于未确认成功而做的下一步（关闭页等）。
实验室里延迟短，不同步看不出。要把确认拉到数秒，并允许用户离开这条记录。
边界
本地即可完成、无服务器的动作没有这层不同步。强一致的支付不应走乐观解锁。协同编辑里未决是常态，按钮可能一直像可用，未决改走文档内的同步指示，而不是按钮锁。自动保存更像未决文档而不是按钮加载。
怎么落地
- 乐观成功时可以结束加载外观，但留下未决标记（淡色、小点、尚未同步），不要装成最终成功。
- 发出时仍做极短的同步锁，防止同一帧双发；未决期间再点应明确是「又一条」还是「还在等第一条」。
- 失败回滚要回到按钮可点，并说明刚才那条没发出去。
- 验证：把服务器确认设为 5 秒后失败。看用户是否在这 5 秒里离开并以为成功，以及回滚时是否还找得到那枚按钮的错误。若界面已空闲得像结束、回滚却像凭空消失，时机就不同步。