Firestore：会话线程回复存为map/array属性而非子集合是否可行？

首先给出明确判断：将线程回复作为Thread文档的数组/Map属性存储的方案在严格限定的业务场景下可行，但存在明确的适用边界，不属于通用的最佳实践，选择前需要先对齐业务的长期规划。

适用场景 #

仅当你的业务完全满足以下所有条件时，可以选择该方案：

• 单条Thread的回复总量有明确的硬上限，且上限对应的总数据量远低于Firestore单文档1MB的大小限制，不会出现超量风险
• 业务侧永远不需要对单条回复做独立的查询、更新、删除、权限控制操作，所有针对回复的操作都是全量读取、全量写入整个回复列表
• 成本控制优先级远高于功能扩展性，当前阶段核心诉求是压低Firestore读写操作的账单成本

不符合最佳实践的核心原因 #

这个方案的问题会随业务规模增长快速暴露，也是通用场景下更推荐用Replies子集合的核心原因：

• 硬上限限制：Firestore单文档最大为1MB，按单条回复平均200字计算，最多可存储数千条回复，一旦业务放开回复量限制，随时会触发写入失败，后期数据拆分迁移成本极高
• 读写效率随回复量下降：每次新增回复都需要先读取全量回复列表、追加内容后再写入整个文档，回复量越大，单次读写的带宽消耗、延迟越高，远不如直接给子集合新增一条文档的效率高
• 功能扩展性极差：后续如果需要做回复分页、单条回复权限控制、回复关键词检索等功能，基于数组/Map的存储方案完全无法实现，必须整体重构存储结构
• 并发冲突风险高：多个用户同时给同一条Thread发回复时，很容易出现写入覆盖的问题，必须额外实现事务逻辑，开发难度远高于子集合方案

折中参考方案 #

如果当前阶段确实需要优先控制成本，可以采用梯度存储的方案：

• 前期单条Thread回复量低于50条时，存储在Thread文档的数组属性中
• 业务逻辑中增加回复量校验，一旦超过阈值自动切换为Replies子集合存储，同时代码层兼容两种存储结构的读取逻辑，不需要用户感知差异

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