嵌入地址是安全的当且仅当地址数量固定、极少变更且总与用户一同读取；否则必须拆分为独立集合并用objectid引用，配合索引与$lookup聚合，同时处理级联删除、ttl及权限粒度问题。
什么时候嵌入地址是安全的
嵌入适用于地址数量固定、极少变更、且总是和用户一起读取的场景。比如注册时填的“默认收货地址”，只存 1 条，字段少（省市区+街道+电话），应用每次查用户必然要一起拉这条地址。
-
address字段是数组但长度稳定 ≤ 3，且新增/删改频率 - 查询逻辑基本是
db.users.findOne({ _id: ObjectId("...") })，从不单独查地址 - 单条地址文档大小
- 地址不被其他集合（如订单、物流）直接引用或关联更新
什么时候必须独立建 addresses 集合
一旦出现以下任一情况，嵌入就会变成技术债：地址变多、变大、变频繁，或需要被多方引用——这时再硬塞进用户文档，会导致写放大、查询低效、索引膨胀甚至 DocumentTooLarge 错误。
- 用户平均有 ≥ 5 条地址，且历史地址需保留（如“最近 10 次收货地”）
- 地址字段含富文本、图片 URL、GPS 坐标、校验状态等扩展字段，单条 > 4KB
- 订单服务、风控服务、物流服务都需要独立查/改某条地址，而非总要先查用户
- 地址修改频次高（如用户频繁切换常用地址），而用户基本信息（姓名、邮箱）几乎不变
- 需要对地址做地理范围查询（
$geoWithin）、模糊匹配（$text），但用户集合已有大量非地理字段索引
db.users 和 db.addresses 怎么高效关联
别用字符串 ID 或手动维护 addressIds 数组——MongoDB 的引用必须可索引、可聚合、可原子更新。推荐明确使用 ObjectId 引用，并在业务层保证一致性。
- 用户文档中存
defaultAddressId: ObjectId("...")，而不是address: { ... } - 地址文档里加
userId: ObjectId("...")字段，并在addresses上建复合索引：db.addresses.createIndex({ userId: 1, isDefault: -1 }) - 查用户+默认地址时，用
$lookup聚合（注意内存限制）：{ $lookup: { from: "addresses", localField: "defaultAddressId", foreignField: "_id", as: "defaultAddress" } } - 避免在应用层做 N+1 查询：不要先查用户，再循环调
db.addresses.findOne(...)
容易忽略的边界问题
最常被跳过的不是语法，而是数据生命周期和权限粒度。地址独立后，删除用户不能简单 db.users.deleteOne() —— 必须同步清理其所有地址，否则产生孤儿文档；同样，地址的读写权限可能比用户更细（比如客服只能改配送地址，不能动注册邮箱）。
- 没配级联删除逻辑，
db.addresses.deleteMany({ userId: user._id })容易漏执行 - 地址集合没设 TTL 索引，废弃地址（如 2 年未用）越积越多
- 用
$push往嵌入式address数组追加时，没设$each + $slice控制长度，数组无限膨胀 - 以为 “嵌入=快”，结果因地址字段太多导致
users集合索引体积翻倍，影响整体查询延迟
