预计算字段应按更新频次与查询需求权衡存储方式：高频更新且仅需读当前值的字段（如count）宜剥离，用原子操作或事务保障一致性；非必要不拆集合，超16MB或更新远高于主文档时才分集合；缓存仅为加速，不可替代DB持久化。
更新频繁的字段别直接存，先想清楚它是不是真要实时查
预计算模式本质是用空间换时间，但很多人一上来就堆冗余字段，结果写放大、一致性难保、还拖慢主文档。核心判断标准就一个：count、latest_message_time、unread_count 这类字段，如果 90% 的查询只是「读取当前值」，而更新又高频（比如每秒多次），那就该剥离。
常见错误现象：find() 返回文档里每次都要 $sum 子数组算总数，聚合管道跑得慢还占内存；或者靠应用层加锁+读-改-写，结果出现竞态导致计数错乱。
- 只在真正需要「最终一致」的场景用——比如未读数允许延迟 1–2 秒，就别强求原子性写入主文档
- 如果字段还要参与
$sort或$match（比如按最新评论时间排序），那必须保证索引可用，不能只靠应用层拼接 - 避免把多个逻辑耦合进一个预计算字段，比如把
status_summary设计成字符串拼接结果，后续没法单独过滤或分组
MongoDB 里怎么安全更新预计算字段：用 findAndModify 或事务
单文档内更新预计算字段最稳的方式是原子操作，而不是先 findOne 再 updateOne。尤其像点赞数、阅读量这种，两个并发请求可能同时读到旧值，各自 +1 后写回去，结果只涨了 1 而不是 2。
正确做法是用 findAndModify（带 upsert: true）或 4.0+ 的多文档事务。但注意：事务有性能开销，别为单字段更新滥用。
- 简单计数优先走
updateOne({ _id: xxx }, { $inc: { view_count: 1 } })—— 它本身就是原子的 - 涉及多字段联动（比如更新
last_reply_time同时要改reply_count），用findOneAndUpdate配returnDocument: 'after'拿回新值，避免二次查 - 跨集合更新（如用户表里存帖子数）必须用事务，且确保所有相关集合都建好索引，否则事务卡住会拖垮整个写链路
预计算字段要不要单独集合？看更新频次和查询模式
不是所有预计算字段都得拆成独立集合。多数时候，和主文档同集合、同文档存储更高效——MongoDB 读一个文档比跨集合 join 快得多，也省去维护外键关系的麻烦。
但以下情况建议拆：stats 集合存每个帖子的阅读/点赞/收藏数；user_summary 存每个用户的活跃度得分。否则主文档膨胀快，备份慢，复制延迟高。
- 主文档平均大小超过 16MB（MongoDB 单文档上限）风险时，必须拆
- 字段更新频率远高于主文档其他字段（比如每分钟更新 100 次，而主文档每小时才改一次），拆开能减少写放大和文档移动
- 如果这个字段常被单独聚合（比如统计全站 TOP100 热帖），单独集合 + 合理索引（
{ view_count: -1 }）比在大文档里$unwind更快
缓存层和预计算字段怎么协同，别让 Redis 成为单点故障源
很多人加一层 Redis 缓存预计算值，结果 Redis 挂了，应用直接报错或返回脏数据。预计算字段本身是数据库层的保障，缓存只是加速手段，不能替代它。
关键原则：缓存失效策略必须和数据库更新同步，且要有降级路径。比如更新 post_stats 集合后，再删 Redis 里的 post:123:stats，而不是等 TTL 过期。
- 不要用 Redis 的
INCR直接当唯一计数源——它没持久化，重启就丢；只用来做「热点临时缓冲」 - 缓存 key 命名带上版本号或更新时间戳（如
post:123:stats:v2），避免旧缓存污染新逻辑 - 应用层读取时，先查缓存，miss 就查 MongoDB 预计算字段并回填缓存；哪怕缓存不可用，也能兜底到 DB，不抛错
最难的其实是更新边界：比如用户删除一条评论，不仅要减 reply_count，还得重算 last_reply_time。这时候不能只依赖触发器或监听 oplog，得在业务代码里显式控制更新顺序和回滚逻辑——这点容易被跳过，但线上出问题基本都栽在这儿。
