Firestore客户端推送速率及文档负载限制是否适用于首次快照？

《Cloud Firestore实时更新最佳实践文档》中提到：

为获得最佳快照监听器性能，请保持文档体积较小并控制客户端的读取速率。以下建议为性能最大化提供指导，超出这些建议可能会导致通知延迟增加。
...
保持数据库推送给单个客户端的文档速率低于1文档/秒。
保持数据库推送给所有客户端的文档速率低于1,000,000文档/秒。
保持单个客户端下载的最大文档体积低于10 KiB/秒。
保持所有客户端下载的最大文档体积低于1 GiB/秒。

疑问 #

1. 这些限制或建议是否同样适用于查询首次返回快照的场景（即首次通过onSnapshot()方法创建快照时）？还是仅适用于快照的更新操作？
2. 若这些限制也适用于首次快照，考虑到Firestore的低延迟特性，通常会超出10KiB/秒尤其是1文档/秒的限制，将会产生哪些不利影响？

解答 #

1. 适用范围说明 #

这些性能建议仅针对实时更新的推送场景，不适用于onSnapshot()首次初始化时的批量数据同步。

文档中提到的“数据库推送给单个客户端的文档速率”，特指数据发生变更后，Firestore主动向客户端推送更新快照的速率，而非首次调用onSnapshot()时一次性返回的所有匹配文档的初始同步过程。初始同步属于批量数据加载，Firestore会针对该场景优化传输效率，不受“1文档/秒”这类实时推送速率限制的约束。

2. 若限制适用于首次快照的不利影响 #

如果强行将实时推送的速率限制套用到初始同步场景，超出阈值会引发以下问题：

• 初始加载延迟剧增：原本可批量传输的初始数据会被拆分成低速分段推送，客户端需要等待更长时间才能获取完整的初始数据集，直接拖慢应用启动或页面加载的用户体验。
• 资源浪费：Firestore底层针对批量同步做了传输优化，强制低速传输会浪费带宽与服务器资源，无法发挥其低延迟特性。
• 监听器稳定性问题：极端情况下，长时间的低速初始同步可能触发监听器连接超时，引发重试逻辑，进一步加剧延迟甚至导致数据不一致。

另外需要注意：即便初始同步不受上述限制约束，若单次初始加载的数据量过大（比如一次性获取上万条大体积文档），仍可能导致客户端内存占用过高、UI卡顿等问题，建议通过limit()结合游标实现分页查询，控制初始加载的数据规模。

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