应显式指定有意义的_id字符串（如"prod-api"），避免用ObjectId或数字；需完全替换配置时用replaceOne，字段级更新可用$set+upsert但须传全保留字段；并发场景应加version校验或findAndModify保证一致性。
用 upsert 存配置前，先想清楚要不要删旧字段
直接用 updateOne({ _id: "app-config" }, { $set: { ... } }, { upsert: true }) 看似省事，但会残留上一次没覆盖的字段。比如上次存了 { db_host: "old", timeout: 5000 }，这次只传 { db_host: "new" }，timeout 还在文档里——这不是更新，是“补丁式写入”。
- 真要完全替换配置，用
replaceOne更安全，但得自己拼完整文档 - 如果依赖字段级更新（比如只改密码、不碰其他），
$set+upsert没问题，但得确保调用方传全所有需保留的字段 - MongoDB 不支持
$unset所有未传字段，别指望靠一个选项自动清理“脏配置”
upsert 的 _id 不能是随机 ObjectId
配置文档通常按应用/环境唯一标识，比如 "prod-api" 或 "staging-worker"。如果用默认的 new ObjectId() 当 _id，每次 upsert 都可能建新文档，老配置还在库里躺着，查的时候还得加时间戳或状态字段来甄别哪个生效。
- 必须显式指定有意义的
_id字符串，比如环境+服务名组合 - 避免用数字型
_id（如1、2），MongoDB 会把它当NumberInt，和字符串"1"不等价，容易查不到 - 如果用复合键需求强，考虑把
_id设为{ env: "prod", service: "api" }对象，但要注意部分驱动对对象_id的序列化兼容性
并发写配置时，upsert 不保证原子性回滚
两个服务同时执行 upsert 更新同一份配置，不会报错，但最终结果取决于谁写得晚。中间状态不可控，尤其当配置含多个相关字段（如 max_connections 和 pool_size）时，可能一前一后写入，导致逻辑不一致。
- 简单场景下，加个
writeConcern: { w: "majority" }能降低丢失概率，但不解决竞态 - 真正需要强一致性？得用
findAndModify或带条件的updateOne（比如检查version字段递增），再配合应用层重试 - 别依赖 MongoDB 的单文档原子性来保护跨字段业务约束——它只保证单次操作内字段修改的原子，不保证两次操作间的逻辑正确
从集合设计看，单文档存配置不是万能解法
把所有配置塞进一个 { _id: "app-config" } 文档，读起来快，但改起来风险高：一次写错可能整个服务起不来；版本回滚只能靠备份或手写旧文档；审计变更也难定位到具体字段。
- 若配置项多、变更多、团队协作频繁，建议按模块拆分文档，比如
{ _id: "db-config" }、{ _id: "cache-config" }，降低误操作影响面 - 加
updated_at和updated_by字段是低成本高回报的做法，出问题时至少知道谁、什么时候动的 - 别忘了索引——哪怕只有 1 条文档，
_id自带索引，但如果你按env字段查（比如找所有测试环境配置），就得手动建索引，否则find({ env: "test" })会全表扫
配置不是越集中越好，关键是改的时候敢点确认，出问题时能三秒内切回去。单文档 + upsert 看似简单，但每个省事的点，都藏着一个得花两小时排查的坑。
