Firestore指定字段内的数组是否有数量限制？点赞功能选数组还是集合？

一、Firestore数组字段的元素上限问题 #

Firestore本身没有针对数组字段设置单独的元素数量上限，但存在单文档最大1MB的硬限制，数组字段的大小会被计入整个文档的总容量。
按照常规用户ID（长度20_{30位字符串）估算，单个数组最多可以存储5}10万个用户ID，超出后会触发文档大小超限错误，写入直接失败。
另外要注意，单文档的写入频率上限为每秒1次，如果你的内容可能出现短时间大量集中点赞的场景，哪怕数组没到大小上限，也会出现大量点赞请求被限流驳回的问题。

二、数组存储 vs 子集合存储选型 #

直接分场景给结论：

• 适合用数组存储的场景
  单内容的点赞量预估最高不超过1万次，且不会出现短时间大量集中点赞的情况（比如个人站点的文章点赞、小众工具的内容点赞）。
  优势：开发成本极低，点赞/取消点赞可以直接用Firestore原生的arrayUnion()/arrayRemove()原子操作实现，不需要额外处理并发冲突；查询主文档时可以同时拿到点赞列表，判断当前用户是否点赞直接查数组是否包含对应用户ID即可，不需要额外查询。

• 适合用子集合存储的场景
  内容可能有超过1万的点赞量，或者存在热点内容高并发点赞的可能（比如社区帖子、短视频平台的内容点赞）。
  方案说明：给每个被点赞的主文档配置一个likes子集合，每个点赞对应子集合内的一条独立文档，文档ID直接用点赞用户的UID即可。
  优势：

  • 没有存储上限，支持百万级以上的点赞存储
  • 点赞/取消点赞操作是单独对子集合文档进行增删，不会修改主文档，天生支持高并发写入，不会触发主文档的写入限流
  • 点赞列表分页查询灵活，不会拖慢主文档的查询速度
    唯一的劣势是需要额外开发子集合的读写逻辑，判断用户是否点赞需要单独查一次对应UID的子集合文档，但该查询是按文档ID精确匹配，性能极高，资源消耗极低。

额外建议 #

无论选哪种存储方案，都建议在主文档中单独维护一个likeCount数字字段存储点赞总数，不要每次查询时实时统计数组长度或子集合文档数，后者的计数成本非常高。如果使用子集合方案，可以配合Firebase Cloud Function监听likes子集合的增删事件，自动同步更新主文档的点赞数即可。

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