Flutter中为何选用实时数据库？而非StreamBuilder搭配Firebase Firestore？

两者确实都能实现实时数据更新，但选择实时数据库往往是因为以下几个特定场景或技术特性的适配：

• 极致低延迟的实时同步：实时数据库是真正的毫秒级推送，数据节点一有变更，客户端立刻就能收到更新，完全适配聊天、实时白板、多人协作这类对延迟零容忍的场景。Firestore的实时更新是快照触发，虽然也能实时，但延迟略高，且是按文档粒度推送，小数据高频更新时的响应速度不如前者。

• 树形数据结构的高效读写：实时数据库采用树形NoSQL结构，适合存储嵌套深但数据量小的实时数据（比如用户在线状态、单条聊天消息）。读取时可以直接定位到某个具体节点，不用拉取整个集合；更新也只需要修改目标节点，传输的数据量极小。而Firestore是文档-集合结构，更适合结构化、大规模数据的复杂查询，用它存高频小更新的话，不仅会产生更多文档读写次数，嵌套过深还会限制查询能力。

• 成本控制更友好：实时数据库按带宽和存储计费，小数据高频更新时，因为只传输变更的节点内容，带宽消耗极低。Firestore则按文档读写次数收费——哪怕你只更新文档里的一个字段，也算一次写操作，高频场景下成本会快速上涨；而且客户端监听快照时，默认会拉取整个文档（字段过滤有局限性），流量消耗也更大。

• 离线同步的无缝体验：实时数据库的离线缓存是树形结构，断网时的本地变更会自动按顺序排队，联网后无缝合并，几乎感知不到离线状态。Firestore的离线缓存是文档级，虽然也支持离线，但对于高频小更新的场景，冲突合并逻辑更复杂，离线时的实时交互体验不如前者顺滑。

• 原生支持特定实时场景API：实时数据库自带onDisconnect() API，几行代码就能实现用户在线状态监测（断网时自动标记离线），这是聊天、社交类APP的刚需。Firestore没有原生的类似能力，要实现同样功能得自己写心跳逻辑，复杂度高很多。

内容的提问来源于stack exchange，提问作者Wasib Hussain