mongodb非图数据库但可模拟图结构，应依查询模式选嵌入或引用：高频连带查询用嵌入，大体量/需索引分页的关联数据用引用；关系带属性须独立集合，纯二元关系可用数组；慎用$lookup，须配索引且限单层小结果集。
MongoDB 本身不是图数据库，但它能通过文档嵌套和引用策略模拟图结构，尤其适合中低复杂度、读多写少、实体属性丰富的知识图谱或社交关系场景。关键不在于“强行建图”，而在于根据查询模式决定数据是嵌入还是分离。
用嵌入（embedding）还是引用（referencing）？看高频查询路径
嵌入适用于“查一个实体时，几乎总要一起拿到关联数据”的场景；引用则适合关联数据体量大、更新频繁、或需要独立索引/分页的场景。
- 军事知识图谱中，“歼-20”文档直接嵌入
technical_parameters、operational_history（含战役名称、时间、角色）、affiliated_units数组——因为查装备必看参数和服役记录，一次find()就能返回全部 - 但“参战战役”若需按时间倒序分页、支持全文检索战役描述，就该拆成独立集合，用
campaign_id引用，再在campaigns集合上建{ timestamp: -1 }和{ description: "text" }索引 - 社交关系中，“用户主页”展示关注数、粉丝数、最近3条互动，这些可嵌入
user文档；但“关注列表”本身若超5000人，就别全量嵌入，改用follows集合 +{ follower_id: 1, followee_id: 1 }复合索引
避免滥用 $lookup：它不是 JOIN，性能代价高
$lookup 在 MongoDB 中本质是左外连接，无索引支持时会全表扫描右集合，深度嵌套下延迟飙升。生产环境应限制在单层、小结果集、有精确等值条件的场景。
- 错误做法：为查“某用户所有关注者的最新动态”，在
users集合上$lookup到posts，再$sort+$limit——这会导致对每个关注者都查一遍posts，O(n)级开销 - 正确做法：预聚合关注者的动态ID列表存入
user文档的recent_post_ids字段，或用单独的feed集合按用户ID分区存储，写时异步填充（fan-out on write） - 若必须用
$lookup，确保被关联集合有对应字段的索引，且localField/foreignField类型严格一致（如都是ObjectId，而非字符串ID）
关系边如何建模：用独立集合还是文档内数组？
关系本身是否需要属性（如“合作时间”“信任度分数”“关系强度”），是决策分水岭。
- 纯二元关系（如“A 关注 B”“A 是 B 的上级”），且无需附加信息，可用双向数组：
userA.following = ["B", "C"]，userB.followers = ["A"]——简单、快读，但删关系需双写、难保证原子性 - 带属性的关系（如“孙权与刘备在208年结盟，联盟等级S”），必须用独立集合（如
alliances），字段含source_id、target_id、relation_type、start_year、level——支持按属性过滤、范围查询、独立索引，也便于后续扩展为多跳遍历 - 军事图谱中，“某雷达部署于某基地”是静态关系，用数组即可；但“某部队在某战役中使用某雷达执行某任务”含时间、角色、效果等属性，必须走独立关系集合
真正容易被忽略的是“变更成本”：嵌入结构改起来快，但一旦高频关系变多、文档膨胀超16MB上限，或需要按关系属性做复杂分析，就得重构；而独立关系集合一开始多几行代码，后期加字段、建索引、跑聚合都更可控。别被“MongoDB 灵活”误导——灵活性的前提，是清楚自己未来半年要怎么查数据。
