mongodb文档结构应按查询需求设计，高频查询字段需建复合索引，避免冗余$lookup；内嵌适用于读多写少的小数据，数组和深度嵌套需警惕性能与限制；$lookup仅用于稳定小数据关联。
直接看查询需求定结构，而不是先想“关系怎么建”。MongoDB里没有外键约束，文档怎么组织，完全取决于你最常怎么查、怎么更新、怎么分页。
高频查询字段必须能直接索引
如果经常按 user_id + status + created_at 查订单，那这三个字段最好都在同一文档里，且要建复合索引：db.orders.createIndex({"user_id": 1, "status": 1, "created_at": -1})。别把 user_id 存在另一个集合里再 $lookup —— 那是关系型思维惯性，会拖慢90%的聚合场景。
- 嵌套字段（如
address.city）也能建索引，但得用点号写全路径：db.users.createIndex({"address.city": 1}) - 数组字段建索引会触发多键索引（multikey），自动为每个元素建条目，注意内存和性能开销
- 避免在频繁更新的字段上建索引，比如每秒改几十次的
view_count，索引维护成本可能超过查询收益
一对少且读多写少的数据适合内嵌
比如用户资料里的 profile、settings、last_login_info，这类数据总量小、不单独查询、几乎不独立更新，就该塞进用户文档里。内嵌后一次 find() 就拿到全部，不用 $lookup 或多次 round-trip。
- 内嵌数组（如
orders）要警惕数量膨胀：单文档超 16MB 就写不进去，MongoDB 会直接报错Document too large - 如果数组元素经常增删，且总数可能达几百上千，优先考虑拆成独立集合 +
_id引用，否则每次更新都得重写整个文档 - 内嵌文档别嵌太深：BSON 层级限制是 100 层，但实际到 5–6 层就难维护了，
user.profile.contact.emergency.phone这种路径已经算危险信号
跨集合关联只在必要时用 $lookup
$lookup 不是不能用，而是代价明确：它本质是左连接，数据量一大就卡。只在以下情况才值得用：
一款AI开发辅助工具，主要用于使用 OpenCLI 工具，可从各类网站及桌面应用中提取数据、下载媒体内容、控制外部 CLI 工具。支持 Bilibili、知乎、小红书、Twitter/X、Reddit、YouTube、Boss直聘、即刻、微博等 30+ 个平台，以及 Cursor、Codex、ChatGPT、Notion 等桌面应用。当用户需要：从社...，适合需要提升相关任务效率的用户。
- 被关联集合数据极稳定（比如
products表基本不改）、体积小（ - 查询结果里只需要关联集合的 1–2 个字段（用
$project提前裁剪，别让 pipeline 拖着整文档跑） - 业务允许最终一致性：副本集延迟可能导致
$lookup查到旧数据
常见误用：用 $lookup 去实时查用户头像 URL——其实这个 URL 完全可以冗余存到用户文档里，毕竟头像改得远不如用户资料频繁。
分片键和查询模式必须对齐
一旦上了分片集群，集合结构就得提前考虑分片键。如果按 user_id 分片，但大部分查询走的是 region + date，那所有请求都会变成广播查询（scatter-gather），性能断崖式下跌。
- 分片键字段必须出现在绝大多数查询的
filter条件里，否则路由失效 - 别选高基数但低查询频率的字段（比如
_id默认 ObjectId），除非你真按 ID 查 - 复合分片键（如
{"user_id": "hashed", "created_at": 1}）能缓解热点，但要求查询至少带user_id
真正容易被忽略的点：嵌套字段不能直接当分片键，必须是顶层字段。想用 address.province 分片？得先把它提到文档根层级，或者用应用层生成的 province_hash 字段替代。
