本地优先：首先在您的设备上运行的软件

每个人使用软件时都有一种感觉：点击某个东西然后等待。光标旋转，屏幕冻结半秒，界面才有反应。这种延迟几乎总是有相同的根源：应用程序需要在给您响应之前与服务器通信。

本地优先方法始于不同的前提。数据首先存在于您的设备上。该应用程序在本地读取和写入，立即响应，然后才在后台与服务器通信。对于使用它的人来说，它就像魔法一样。对于那些建造者来说，这是一个具有深远影响的建筑决策。

传统模式及其隐形瓶颈

我们使用的大多数系统都是以服务器为中心而诞生的。浏览器或应用程序是一个薄壳：它显示界面，但真相存在于远程数据库中。每一个相关的行动都成为一个请求。

您编辑一个字段，应用程序将其发送到服务器，等待确认，然后更新屏幕。当网络快速且稳定时，此循环效果良好。问题在于，快速稳定的网络只是一种假设，而不是保证。

在地铁里，在电梯里，在信号微弱的地方，在拥挤的活动中，一千部手机争夺同一个天线，模型崩溃了。该接口受延迟影响。延迟，即使很小，也是昂贵的：每一百毫秒的等待都会削弱人们对产品质量的看法。

有一个细节经常被技术领导者低估。服务器指标中没有出现瓶颈，服务器指标仍然正常。它出现在真实的用户体验中，仪表板看不到的地方。

本地优先颠倒了操作顺序。数据的主要来源成为设备。服务器不再是操作发生的地方，而是成为稍后同步操作的地方。

当您编辑某些内容时，更改会写入本地，并且界面会立即响应。无需等待远程确认。同时，同步过程会在可能的情况下将此更改传送到服务器，并带回其他用户或设备更改的内容。

这种倒置产生了三种相互加强的效应。第一个是感知速度：响应是即时的，因为它不依赖于网络。第二个是弹性：应用程序在没有连接的情况下继续工作，因为连接从来都不是操作的先决条件。第三个更微妙，也更政治化，值得单独专门讨论。

当数据首次存在于用户设备上时，权力关系就会发生变化。在传统模式中，如果服务离线或公司关闭其活动，您的数据也会随之消失。你实际上从未拥有过它们，你只是租用了访问权限。

本地优先有一个隐含的论点：用户应该拥有其数据的工作副本，即使服务器消失，该副本仍然有用。这不仅仅是技术上的便利，也是关于谁负责什么的立场。

对于针对专业人士的产品来说，这个论点很重要。建筑师、律师、研究人员都有合法的动机不被第三方服务的可用性所束缚。他们工作的连续性不能取决于远程基础设施的状态。

我在这里有一个坚定的观点：将数据所有权视为产品差异化因素，而不是实施细节，是团队当今可以采取的最明智的举措之一。信任很难建立，但很容易失去。

本地优先并不是一个新概念。像 Git 这样的版本控制系统多年来一直以这种方式工作：您在计算机上拥有整个存储库，离线工作，并在需要时进行同步。改变的是它周围的工具。

浏览器获得了重要的本地存储以及在设备上运行复杂逻辑的能力。同步理论已经成熟，数据结构知道如何合并并发编辑，而无需中间的仲裁服务器。人们口袋里的硬件已经变得足够强大，可以进行实际处理，而不仅仅是显示。

再加上累积的挫败感。多年来，缓慢的应用程序在没有信号的情况下崩溃，并将离线视为错误，这引发了人们对更好的东西的渴望。由于很少有真正提供流动性的产品推动了预期标准的上升。

任何想要深入研究使同步可靠的机制的人都会喜欢了解[CRDT 如何解决数据冲突1]，因为这是许多艰苦工程的所在。

值得诚实的是：并非每个系统都应该是本地优先的。这种方法需要付出代价。你开始在两个地方维护数据逻辑，你需要考虑编辑冲突，测试变得更加复杂。它不是免费的。

用户与自己的数据进行大量交互的应用程序可以获得很多收益。编辑器、生产力工具、注释应用程序、现场工作系统，所有这些都自然地符合这个想法。

需要以事实为中心且唯一的系统，例如金融交易、座位预订或实时共享库存，需要更多的关注。并不是说本地优先在那里不可能，而是业务规则要求某些决策在单个协调点上进行，而强制执行该标准会带来更多的风险而不是价值。

我使用的标准很简单。如果大多数用户操作可以在本地确认而无需咨询任何人，那么本地优先是一个强有力的候选者。如果几乎每项行动都需要中央权威机构来验证，那么请三思而后行。

将入门成本与维护成本分开也是值得的。组装第一个本地优先版本需要付出努力，但随着时间的推移而演变需要纪律。每种新类型的数据都需要决定如何同步和解决冲突，而这笔费用会不断增加。一开始忽视这一点的团队后来会付出代价，以难以重现的错误和没有明显解释的分歧的数据的形式出现。

本地优先并不是一种框架时尚，它是从数据真相开始的转变。这一决定会影响产品、体验、基础设施，甚至与软件使用者的信任关系。

在采用之前，请提出正确的问题：即使没有完美的网络，我的用户是否也需要快速采取行动并继续工作？如果答案是肯定的，那么投入精力是值得的。回报出现在最重要的地方，即产品简单有效的感觉。

如果您领导一个团队并正在评估这种转变，那么值得首先了解应用程序的实际设计，该应用程序[将离线视为正常状态2]，因为这就是理论变成实际代码的地方。