首次使用Firebase Firestore开发旅行应用，读写与带宽激增求助

一、高概率导致读量、带宽虚高的常见操作 #

• 活动列表页是否挂载了整个/activities集合的实时快照监听？这是新手开发的最高发高频坑：只要集合内任意一条文档发生改动，哪怕和用户当前浏览的分页内容完全无关，SDK也会把匹配规则的所有文档全量重新拉取，单次操作就能凭空产生数百次读请求，无缓存的重复传输还会大幅消耗带宽。
• 列表加载是否拉取了活动文档的全部字段？比如把活动逐天行程、组织者联系方式、已报名用户完整列表这些列表页根本用不上的字段全量拉到端上，单条文档的传输体积会翻3-5倍，带宽消耗自然远超预期。安卓端Firestore SDK 24.4.0以上版本支持字段投影查询，列表页仅拉取活动标题、封面链接、价格、剩余名额、所在城市几个核心展示字段，就能把列表页的读带宽压缩到原来的1/3以下。
• 是否把图片这类大体积文件以base64格式存在Firestore文档字段里？这类操作会让单条文档体积膨胀到几百KB，哪怕只拉一次也要消耗大量带宽，图片资源统一存在Storage中，文档内仅保存可公开访问的图片链接即可。

二、高概率导致写量虚高的常见操作 #

• 是否在前端做无节流的活动浏览量实时累加？比如用户打开活动详情页就直接执行viewCount +=1的写操作，没有做节流逻辑的话，用户下拉刷新、切后台切回、网络重连都会重复触发写入，写量会随用户操作频次无意义上涨。这类统计逻辑放到Cloud Function中基于真实访问事件批量汇总即可，不要让前端直接发起高频写请求。
• 预约关系是否存在无意义的冗余写入？比如在/activities/{activityId}/bookings的预约子文档里，重复存储预约用户的头像、昵称、手机号这类已经在公共用户集合中存在的字段，每次新建预约都要重复写入冗余内容，不仅增加写次数，还会让单条预约文档体积变大，提升读写时的带宽消耗。实际仅需在预约子文档中存储用户uid、预约状态、预约时间戳即可，需要展示用户信息时再从公共用户集合关联拉取，不要重复存冗余字段。

三、适配探险活动预约场景的低开销数据模型参考 #

• 根集合/activities：仅存储活动列表展示需要的轻量字段，为每个活动分配固定文档ID，针对常用筛选维度（活动类型、出发城市、可报名状态）创建复合索引，分页拉取时每次仅获取20-30条，避免一次拉取全量文档。
• 嵌套子集合/activities/{activityId}/content：单独存储活动的长文本介绍、行程明细、注意事项这类体积大、仅在详情页需要的内容，用户点击进入详情时再单独拉取这个子文档，不要和列表字段混存在同一个活动文档中，从根源减少列表加载时的无效带宽消耗。
• 根集合/userBookings/{userId}：为每个用户单独创建一份文档，用数组类型存储该用户的所有预约条目（关联活动ID、预约状态、预约时间），用户打开“我的预约”页面时，仅需拉取自己对应的那一个文档就能拿到全部预约记录，无需遍历全平台所有活动下的所有预约子文档，这一项就能将个人中心的读量降低90%以上。
• 活动名额扣减统一使用事务操作：拉取活动当前剩余名额、校验名额充足、扣减剩余名额、生成预约记录这几个步骤放在同一个事务内执行，不要由前端分步发起多次读写，减少无效的写请求。

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