Firestore数据优化：多布尔字段与单Map字段哪种更节省成本？

从Firestore的计费逻辑（文档大小+读写次数）出发，我们逐一对比你的两种方案，再补充其他优化思路：

1. 单独布尔字段 vs 单个Map字段 #

存储成本（文档大小） #

Firestore计算文档大小时，会统计每个字段的完整路径长度加上对应值的大小：

• 单独布尔字段：比如follow、comment、like、mention四个字段，每个布尔值占1字节，加上字段名长度（假设平均5字节），总大小约为4*(5+1)=24字节。
• 单个Map字段：比如用notificationSettings作为顶级字段，内部嵌套四个键值对，每个键的完整路径是notificationSettings.follow（比单独字段的路径长很多），总大小会比单独字段方案大30%-50%左右。

结论：单独布尔字段的存储成本更低。

读写成本 #

• 修改单个设置：两种方案都可以通过update操作直接修改目标值（Map方案可以用点路径notificationSettings.follow更新），都只产生1次写操作，成本一致。
• 批量修改：两种方案都能一次update完成多个设置的修改，成本无差异。

2. 更极致的优化方案：位掩码（Bitmask） #

如果你的推送类型固定（目前4种，未来不会大幅增加），可以用整数位掩码存储设置：

• 用整数的每一位代表一个推送类型的开关：比如第0位=关注、第1位=评论、第2位=点赞、第3位=其他操作。
• 存储一个整数（比如0b1011代表开启关注、评论、点赞，关闭其他），Firestore中整数占8字节，加上字段名（比如notifyMask），总大小仅约15字节，比单独字段更省空间。

但注意：

• 修改单个设置时，需要先读取当前掩码值，通过位运算修改后再写回，会产生1次读+1次写操作，读写成本比单独字段高。
• 只适合推送类型数量少（比如≤10种）且不频繁新增的场景，否则位运算逻辑会变得复杂。

最终选择建议 #

• 如果用户修改推送设置的频率较高：优先选单独布尔字段，平衡存储和读写成本，且代码逻辑更直观，易维护。
• 如果用户很少修改设置，且追求极致存储优化：可以考虑位掩码方案，但要接受修改时的额外读写成本。

内容的提问来源于stack exchange，提问作者황희윤