什么是「乐观更新」
通常，客户端在发起 CRUD 请求之后，都需要等待服务端返回，然后再去更新视图。这逻辑非常合理，一点毛病没有。唯一的缺点，就是在等待服务端响应的时间里，客户端只能空等，直观感受就是：用户从交互结束，到看到结果，中间免不了会有一个可感知的延迟。稍微对用户体验有所追求的，都会在这个时候显示一个 Loading，让用户知道系统还在运行。
如果你体验过 Google 家的产品，你一定会惊叹于其交互的响应速度，那种按下按钮之后立刻得到结果的快感，就好像一切都发生在本地，根本不用等待接口响应一样。Google 之所以能做到这种程度，并不是因为它是 Google —— 一个掌握着浏览器、网络协议、V8 引擎等核心技术的互联网巨头。人家的方案非常简单：真就是不等待接口返回，请求发出去的同时，直接就把交互的结果体现到视图上。
这就是「乐观更新」：客户端假设请求必然成功，因此不等待接口的返回，先行对视图进行更新。
这么乐观，适用所有场景吗？
乐观虽好，但我们也不能盲目乐观。并不是所有操作都可以通过「乐观更新」的方式来实现，需要有一些前提条件：
操作成功率非常高，大概率是不会失败的。
接口正常响应的耗时很短，不涉及大规模的计算或 IO。
操作可逆，失败了可以撤销。
像发送一条消息、删除一个文件，这些都是可以考虑「乐观更新」的，能够大幅提升用户体验。
你能接受每发一条微信消息都要等个半秒钟它才会出现在屏幕上吗？Windows 10 中删除到回收站的默认行为已经不会弹确认框了你发现了吗？
反过来，像文件传输、鉴权相关的操作，就不适合「乐观更新」了。
你能想象迅雷还没开始下载就直接显示下载完毕了吗？或者用支付宝付款的时候，先显示支付成功，然后才告诉你余额不足被撤单吗？