replaceOne全量覆盖最稳妥，因其确保文档原子性、避免状态不一致；增量更新仅适用于$inc/$push等无依赖幂等操作；大文档需拆分以保障性能。
用 replaceOne 全量覆盖存档最稳妥
游戏角色数据天然适合文档模型，但“全量覆盖”不是偷懒，而是避免状态不一致的核心手段。MongoDB 没有行级锁或事务级更新保障（尤其跨字段依赖时），replaceOne 能确保整个 character 文档原子性生效——哪怕字段从 20 个涨到 50 个，也不用反复校验哪些字段该更新、哪些该保留。
常见错误现象：updateOne 配合 $set 局部更新后，旧字段残留（比如技能列表里删掉一个技能，但没显式 $unset，它还在）；或者并发写入时，两个客户端各自改了不同字段，后写的覆盖前写的修改。
实操建议：
- 存档结构按「单角色单文档」设计，根级字段语义清晰（如
name、level、inventory、quests），不嵌套过深 - 写入前在应用层生成完整文档快照（含默认值填充），再调用
replaceOne，不要拼接 partial doc - 务必设置
upsert: true，避免首次创建和后续更新逻辑分裂 - 如果存档体积常超 16MB，说明设计越界了——该拆分（如把日志、聊天记录移出主文档）
增量更新只在特定场景下安全：计数器类字段
真正适合用 $inc、$push、$pull 的，只有无依赖、可交换、幂等的字段，比如金币数量、成就点数、背包里新增道具。这类操作由 MongoDB 内置原子指令保证一致性，不需要你操心并发。
使用场景有限：仅限于「加减」「追加/删除数组末尾项」「布尔翻转」这三类。一旦涉及条件判断（如“金币够才扣”）、多字段联动（如“扣血同时设濒死状态”）、或数组中间位置操作，就必须退回到全量覆盖。
性能与兼容性影响：
-
$inc在高并发计数场景比replaceOne快 3–5 倍，且不触发文档移动（因不改变大小） - 但
$push带$each+$slice时，可能隐式重写整个数组字段，实际开销接近全量更新 - MongoDB 6.0+ 对
$setOnInsert支持更好，适合初始化字段，但别指望它替代业务逻辑
别信“部分更新更省流量”——网络传输不是瓶颈
有人坚持用 $set 只传改动字段，以为能省带宽或加速。现实是：一次 HTTP 请求的固定开销（TLS 握手、TCP 建连、序列化反序列化）远大于多传几百字节 JSON。而应用层维护“变更集 diff”逻辑的成本，远高于直接传完整对象。
容易踩的坑：
- 前端 JavaScript 对
undefined/null/ 空数组处理不一致，导致$set后字段意外消失或变成null - 后端 ORM 或 ODM（如 Mongoose）自动过滤空值，结果
inventory: []不进数据库，下次读出来却是inventory: undefined - 忘记对时间戳字段（如
updatedAt）做统一更新，靠$currentDate又无法控制精度（毫秒 vs 秒）
实操建议：所有写请求统一走完整文档 + replaceOne，时间戳由服务端生成并写入，不依赖驱动自动行为。
大文档（>1MB）必须警惕内存与查询延迟
角色存档超过 1MB 不罕见（尤其带装备纹理路径、技能动画帧、历史操作日志），但这会直接拖慢 find 和 replaceOne——MongoDB 必须把整个文档加载进内存才能序列化/反序列化，即使你只查 name 字段。
真实影响：
- 查询响应 P95 延迟从 10ms 涨到 200ms+，尤其在副本集从节点上更明显（内存压力大）
- WiredTiger 缓存效率下降，挤占其他热点文档空间
- Driver 解析大 JSON 容易触发 V8 内存限制（Node.js）或 GC 暂停（Java）
解决方案不是压缩，而是拆分：
- 主文档只留核心状态（
_id、name、level、position、updatedAt） - 高频读写但低关联的数据，单独建集合（如
character_inventory，用characterId关联） - 纯日志类数据（如战斗记录），用 TTL 索引自动过期，不混在主档里
拆分后，replaceOne 主档几乎无延迟，而辅助集合可按需增量更新，各司其职。
