在乐观加载和乐观保存之外，还有另一种让应用感觉更快的技巧：乐观提交。

Flickr 就是一个很好的例子。进入照片上传页面后，你会来到一个类似前厅的准备区，可以把照片拖进来、重新排序、命名、打标签，完成各种准备工作，然后再按下醒目的 Upload 按钮。

但 Flickr 会乐观地假定你最终一定会按下那个按钮，于是在你把照片拖进来的那一刻，就已经在后台悄悄开始上传这些体积较大的照片了。

像所有乐观策略一样，对用户更友好，就意味着对 Flickr 的设计师和工程师来说更复杂。毕竟，在你真正确认上传之后，仍然会弹出一个常规的上传弹窗……

……所以这两种状态——准备区的静默上传和正式的可见上传——必须相互协调、保持同步。

此外，那些已经乐观地开始上传、但最终被取消的上传，还得从服务器上清理掉。

最后，还有指示标识的问题。与通常假装没有发生任何数据传输、从而简化现实的轻量级乐观加载方案不同，这里的乐观提交实际上是通过一些细小的指示器让用户看得见的：

我认为这种透明度是值得肯定的。过去，Meta（还能是谁！）就曾因滥用乐观提交而惹上麻烦：

你是否曾在 Facebook 上录过一段想直接发到朋友主页的视频，结果删掉重录了一版？你可能以为那些尴尬的草稿版本已经被删掉了，但 Facebook 却保留了一份。公司将其归咎于一个“bug”，并发誓这次一定会把那些被丢弃的视频删掉。这次他们可是拉钩保证了。

在这种背景下，Flickr 能明确告知数据正在被发送到服务器是件好事；我相信这有助于建立信任。

除了透明度之外，我认为这个过程能非常精确地展示上传进度也很好——不仅能看到文件之间的进度，还能看到每个文件内部的进度。网速的差异非常大，不仅因地域而异，甚至在不同场景下也会有很大波动，所以在实践中这一点真的很有帮助。很多时候，自动保存到云端只要不在较长时间内断网，就没必要去打扰用户，但在这种场景下，清晰明了显然比“魔法般”的无感体验更好。