用独立布尔字段 is_primary，不要依赖数组索引；地址嵌套在用户文档中更合理，但超200条或需聚合统计时应拆分集合。
主地址用布尔字段 is_primary 还是靠数组顺序？
直接结论：用独立布尔字段 is_primary，不要依赖数组索引位置判断主地址。MongoDB 数组本身无内置“默认排序语义”，addresses[0] 是主地址这种约定，会在更新、并发写入或应用逻辑变更时迅速失效。
常见错误现象：findOneAndUpdate 只改了某个地址的 city，却忘了同步维护 addresses[0] 的一致性；或者前端批量提交地址时顺序被打乱，导致后端误判主地址。
- 所有地址操作（增/删/设为主）必须原子更新
is_primary字段，且确保有且仅有一个为true - 查询主地址时用
{ "addresses.is_primary": true }，而非{ "addresses.0": { $exists: true } } - 建模时在
addresses数组每个元素里显式包含is_primary: boolean，不额外存顶层字段
地址数组嵌套在用户文档里，还是单独集合？
95% 场景下嵌套更合理。收货地址天然强归属用户，读多写少，单次查询需拉取全部地址（如结算页），嵌套能避免多次网络往返和应用层 join。
但要注意嵌套的硬限制：单个文档上限 16MB，实际建议控制在 100 条以内地址（每条约 2KB，含历史字段如 updated_at、deleted_at）。
- 如果业务允许用户保存超 200 条地址（比如 B2B 批量采购场景），或需按省/市聚合统计地址分布，就该拆成独立集合，加
user_id索引 - 嵌套方案下，删除地址别用
$pull后再$set主地址——用findOneAndUpdate一次完成：先$pull被删项，再$set剩余中第一个非删除态的is_primary为true - 加
updated_at字段到每个地址子文档，方便前端做局部刷新，不用每次全量重载
如何安全地切换主地址？
切换本质是两步原子操作：把原主地址的 is_primary 设为 false，再把目标地址设为 true。必须用单次 findOneAndUpdate 完成，否则中间状态会导致订单创建取到空主地址。
错误写法：先查出当前主地址 _id，再发两个 update 请求——这之间可能有其他写入覆盖状态。
- 推荐写法：
db.users.findOneAndUpdate( { _id: userId }, [ { $set: { "addresses.$[elem].is_primary": false } }, { $set: { "addresses.$[elem2].is_primary": true } } ], { arrayFilters: [ { "elem.is_primary": true }, { "elem2._id": targetAddressId } ] } ) - 务必在
addresses.is_primary上建复合索引：db.users.createIndex({ "addresses.is_primary": 1, "addresses._id": 1 })，加速查找 - 应用层要处理
matchedCount === 0情况——说明目标地址不存在或已被删除，不能静默失败
地址变更历史要不要保留？
要，但别全量存。用户改个手机号或邮编，没必要留完整快照。更实用的做法是：只在地址被标记为 deleted_at 时归档，其余更新直接覆盖。
容易被忽略的点：地址里的 province/city 字段如果后期要做行政区划升级（比如某县升格为区），旧数据需要可追溯。这时应在每次更新时追加 version 或 schema_version 字段，而不是依赖时间戳。
- 归档地址另存到
archived_addresses集合，保留原始_id和user_id，方便审计 - 日常更新只写
updated_at，不写history数组——数组膨胀会拖慢查询，且绝大多数场景不需要逐次修改记录 - 如果真需要完整历史（如金融合规要求），用变更流（Change Streams）监听
addresses更新，异步写入历史表，不阻塞主流程
