如何在Firestore中存储大小超过1MiB的用户撰写文章内容？

以下是两种经过生产验证的可行方案：

方案一：Firestore文档分块存储 #

直接在Firestore生态内实现，无需对接其他服务：

• 将文章正文按固定大小拆分，推荐单块大小设置为900KB，预留足够空间存储块序号、校验值等元数据，避免触达单文档1MiB上限
• 主文章文档仅存储标题、作者、发布时间、总块数、内容校验哈希等元数据，拆分后的内容块单独存储在主文档下的content_chunks子集合中，每个块文档按序号命名便于拼接
• 读取时并行拉取所有块文档，按序号拼接后即可得到完整正文
• 优缺点：读写逻辑和Firestore现有权限规则完全复用，延迟稳定；缺点是会消耗更多文档读写额度，单篇拆分为N块的文章读取一次会消耗N+1次读配额

方案二：Cloud Storage + 缓存优化方案 #

针对你担心的加载速度问题做针对性优化后，体验几乎无感知：

• 文章正文存储到Cloud Storage前先做gzip压缩，普通文本类内容压缩率通常可达70%以上，大幅降低传输体积
• 给Storage桶配置CDN缓存，静态文本类内容的缓存命中率极高，非首次访问时直接由边缘节点返回，速度远高于普通源站拉取
• 客户端增加本地缓存逻辑，将拉取过的文章正文存在本地存储（如IndexedDB、Hive等），同账号下二次打开直接读取本地内容，无需重复发起网络请求
• 优缺点：存储和流量成本远低于Firestore，单文件支持最大5TB，完全无需考虑大小上限；缺点需要单独配置Storage安全规则，首次未命中缓存时的拉取延迟略高于Firestore分块方案

选型建议 #

• 若你的应用单篇文章平均大小在1~10MiB区间，且读写频率较高，优先选择Firestore分块方案，逻辑更简单无需额外配置
• 若单篇文章普遍大于10MiB，或用户量级较大需要控制成本，优先选择优化后的Cloud Storage方案，长期成本优势非常明显

内容的提问来源于stack exchange，提问作者Cyril N.