什么是乐观界面，以及何时使用

乐观式界面是一种用户体验模式：应用假定变更操作会成功，并在服务器响应之前立即更新界面。用户可以立刻看到操作结果，而实际的网络请求会在后台进行。如果请求成功，界面无需改变；如果请求失败，界面就会回滚。

网络请求，尤其是在移动设备或网络连接较慢时，会产生延迟，使应用感觉迟钝。乐观式界面消除了这种延迟感。用户点按点赞按钮的瞬间，按钮状态就会切换；用户添加项目的瞬间，项目就会出现在列表中。即使网络状况不佳，应用仍然感觉响应即时。

当变更操作极有可能成功，且出错的代价较低时，适合使用乐观式更新。合适的场景包括：切换点赞或书签、向购物清单添加项目、更新设置偏好，以及在拖放列表中重新排列项目。这些都是影响较小的操作，短暂的不一致通常可以接受。

对于高风险或不可逆的操作，不适合使用乐观式界面。请勿将其用于：金融交易（在服务器确认前就显示付款成功）、永久删除记录、创建需要服务器端验证的记录（唯一用户名、邀请码），或任何可能因虚假成功而导致数据损坏的操作。

每次乐观式更新都必须有回滚方案。当服务器因冲突、授权错误、验证失败或网络超时而拒绝变更操作时，界面必须恢复到之前的状态。如果未实现回滚，界面就会处于不一致状态，不再反映实际情况。

当乐观式更新失败并回滚后，用户需要知道发生了什么。最佳做法是显示一条不打扰用户的错误提示，或显示一条内联错误消息，解释出错原因并提供重试操作。回滚过程应当平滑，避免突兀的界面跳变令用户感到困惑。

骨架屏加载器会在等待数据加载时显示占位内容——它们并不会消除等待，只是让等待过程不那么空洞。乐观式界面则通过立即显示最终状态，彻底消除用户感知到的等待。骨架屏用于初始数据获取；乐观式更新用于变更操作。它们解决的是不同的问题。

乐观式界面之所以有效，是因为绝大多数变更操作都会成功。用户切换点赞按钮时，请求成功的概率通常超过 99%。围绕成功路径进行设计，并妥善处理罕见的失败情况，比每次都让所有用户等待服务器确认更加友好。

在 Twitter、Gmail 或 Slack 等应用中体验过乐观式界面的用户，会逐渐形成即时响应的预期。相比之下，每次操作都要求显示加载旋转图标的应用会显得迟缓。建立这种预期是现代产品设计的一部分——响应迅速的界面已经不再是可有可无的功能。

在某些情况下，您可以在变更操作进行期间显示细微的不确定性提示。将状态显示为灰色、在项目本身显示一个小型旋转图标（而不是阻塞整个界面），或显示“正在保存……”提示，都能让用户知道操作正在等待完成，同时不妨碍交互。这是在完全乐观式处理与阻塞式加载器之间的折中方案。

乐观式界面会增加复杂性：您需要管理之前的状态以便回滚，处理竞态条件，协调临时 ID，并清楚地传达失败信息。对于频繁且风险较低的变更操作，这种权衡是值得的。对于失败模式复杂且影响重大的变更操作，增加的复杂性可能不值得其带来的用户体验收益。

乐观式界面会在服务器确认之前更新界面，让应用感觉响应即时。请将其用于影响较小且成功率较高的变更操作（点赞、添加列表项目、设置）。避免将其用于金融操作、不可逆的删除操作或需要服务器验证唯一性的操作。每次乐观式更新都需要回滚方案。使用错误提示传达失败信息，并提供重试选项。其代价是增加复杂性，换来显著更快速的用户体验。