Google Docs把15年API惯例撕了，实时协作成了新基建|websocket|新基建|服务器|流式

过去15年，软件系统之间的对话方式几乎没变：你问，我答，完事。RESTful API（表征状态转移应用程序接口）这套模式干净、直接、好用，我们靠它堆出了无数产品。但2006年Google Docs上线多人实时编辑那天，有个问题没人敢大声问：如果文档能这样协作，凭什么其他东西不行？

15年后，这个问题正在重写基础设施的底层逻辑。Firebase让数据库自动同步到每个客户端，断网也能用，重连自动追平。Pusher把实时发布订阅（pub/sub）从数月工程压缩成一下午的配置。LaunchDarkly把功能开关（feature flags）做成离线也能跑的本地缓存。Convex让数据库查询像React组件一样自动刷新。

这些产品的共同点？它们不再等你开口问。

从"请求-响应"到"持续连接"

传统基础设施的运作方式像餐厅点餐。你需要数据，发起API调用，等服务端响应。聪明人会加缓存，但缓存失效策略是计算机科学三大难题之一。你得写重试逻辑、处理超时、对抗脏数据。把一件本该简单的事做可靠，反而成了工程负担。

流式基础设施把这个模型倒了过来。服务通过WebSocket（一种全双工通信协议）维持与应用的常连接，数据一变就推送到客户端。应用本地持有所需状态的副本，读取时直接查内存，不再走网络请求。

LaunchDarkly的做法很典型：启动时把所有功能开关流式推送到应用，后续本地内存读取。判断if (flags.newFeature)时，你访问的是本地缓存，不是HTTP接口。速度快，且LaunchDarkly服务挂了也能用最后已知值兜底。

Firebase更激进：整个数据库都这么干。查询一次，后续自动同步。别的用户改了数据，服务器主动推给你。你写的代码响应的是本地状态变更，不是网络回调。

为什么现在成了气候

技术债的积累有个临界点。当实时协作从"Google才有的魔法"变成用户基线预期，继续用API轮询就像用拨号上网刷短视频——不是不能，是丢人。

Convex的CEO James Cowling提过一组数据：他们的客户里，把传统API迁移到响应式查询后，前端代码量平均减少40%。不是开发者变懒了，是大量样板代码——加载状态、错误处理、缓存失效——变得没必要了。

更隐蔽的收益在网络韧性。LaunchDarkly的客户包括一些交易频率极高的金融系统，它们的架构师明确提过：功能开关服务中断时，应用必须继续运行，不能降级、不能卡顿。流式架构让"依赖服务故障"从灾难变成可接受的场景。

Firebase的离线优先设计同理。地铁里改文档，出地面自动同步——这个体验15年前是魔法，现在是及格线。

谁在押注，谁在观望

adoption曲线已经分化。Figma、Notion、Linear这些新一代生产力工具，实时协作是出生就带的基因。它们的竞争对手如果还在用"刷新看更新"，用户流失率数据会很难看。

但基础设施层的渗透更值得关注。Vercel的AI SDK现在默认支持流式响应，大模型的token（文本单元）逐个推送到前端，而不是等整段生成完毕。Clerk把用户认证状态做成实时同步，多设备登录体验从"可能不一致"变成"必然一致"。

观望者的问题通常是迁移成本。现有系统绑定了大量API集成，推倒重来不现实。对此， industry's response是渐进式方案：Supabase的实时扩展让PostgreSQL（一种开源关系型数据库）支持流式订阅，不改数据库本身；Electric SQL在现有Postgres上叠加同步层，应用可以逐步迁移。

一个细节值得玩味：这些流式基础设施的定价模型，往往按"活跃连接数"而非"API调用数"计费。这倒逼架构师重新思考——哪些数据值得维持长连接，哪些可以退回到传统模式。商业模型在塑造技术选择。