嵌套数组适合读多写少、深度≤3的场景，但修改复杂且有16MB限制；引用模式（parentId+单集合）最灵活，支持无限级和高效统计；$graphLookup可一次性展开树形结构，但需设maxDepth并建parentId索引；分页应避免skip，改用时间戳+ID游标。
直接用嵌套数组存回复，读得快但改得疼
如果评论以“读多写少”为主（比如新闻、博客类场景），把子回复直接塞进父评论的 replies 数组里是最省事的方案。MongoDB 一次查出整棵树，前端渲染零额外请求。
但代价明显：每次有人在某条回复下再回复，就得用 $push 往深层数组里追加；要是想给某条孙子级回复点赞，就得用带索引的更新语法（如 replies.0.replies.2.like），一不小心就写错路径；更麻烦的是，单文档不能超过 16MB，热门评论堆到几百层，很容易撑爆。
- 适合场景：
depth ≤ 3、平均每条评论回复数、修改频率低（如不支持编辑、仅限点赞/删除） - 避免深嵌套：别让
replies里再套replies，而是统一扁平化为replies: [{...}, {...}]，靠parentId关联回溯 - 必须建索引：
db.comments.createIndex({"articleId": 1, "createdAt": -1})，否则分页查最新评论会全表扫
用引用模式（parentId + 单集合）最灵活也最常用
所有评论（根评、回复、回复的回复）都存在同一个 comments 集合里，靠 parentId 字段指向父评论的 _id，根评论则设 parentId: null。这是平衡可维护性、查询能力和扩展性的主流做法。
它天然支持无限级，删一条评论时只需删它自己（不用递归清空数组），也能轻松做统计（比如查某用户发过多少回复：{fromUserId: ObjectId("..."), parentId: {$ne: null}}）。
- 关键字段示例：
_id、content、fromUserId、toUserId（被回复人）、articleId、parentId（ObjectId或null）、createdAt - 查某篇文章全部评论+一级回复：
db.comments.find({$or: [{articleId: "xxx", parentId: null}, {parentId: {$in: [id1,id2,...]}}]})，但注意这需要先查一遍根评再取 ID —— 更推荐用聚合管道$graphLookup一次性展开（见下一条） - 别漏掉
db.comments.createIndex({"parentId": 1})，否则按父 ID 查子评就是慢查询
要展开多级树？别手写递归，用 $graphLookup 聚合
前端要渲染完整评论树，又不想发 N 次请求？MongoDB 4.0+ 的 $graphLookup 就是为此设计的——它能在服务端递归关联，把一棵评论树一次性查出来。
但要注意：它不是 SQL 的 JOIN，不能跨集合做任意深度关联；必须指定最大深度（maxDepth），且性能随深度线性下降。实际项目中设 maxDepth: 3 就够用了，再深的回复通常折叠显示。
- 典型用法：
{$graphLookup: {from: "comments", startWith: "$_id", connectFromField: "_id", connectToField: "parentId", as: "replies", maxDepth: 2}} - 慎用
restrictSearchWithMatch：如果加了复杂条件（如只查“未删除”评论），可能提前截断树结构 - 聚合结果体积大，记得用
$project投影精简字段，别把整个用户文档（含头像 URL、密码哈希）都带进来
分页查评论列表？永远别用 LIMIT OFFSET
当评论数破万，skip(1000) 不是跳过 1000 条，而是让 MongoDB 先排序、加载、丢弃前 1000 条——CPU 和内存都在白烧。
真实线上系统一律改用“时间戳 + ID”游标分页：查第一页传 limit=20，返回最后一条的 createdAt 和 _id；下一页就查 {createdAt: {$lt: lastTime}, _id: {$lt: lastId}}，再加复合索引加速。
- 索引必须包含排序字段：
db.comments.createIndex({"articleId": 1, "createdAt": -1, "_id": -1}) - 注意时钟漂移：如果用服务器时间生成
createdAt，多节点部署时可能有毫秒级误差，导致漏数据或重复——稳妥做法是用ObjectId的时间戳部分（_id.getTimestamp()）做兜底排序 - 不要在聚合管道里对
$graphLookup结果再做$skip/$limit，它会先展开整棵树再裁剪，极慢
真正难的不是建表，是决定“哪些字段必须实时一致”和“哪些可以异步计算”。比如点赞数要不要实时更新？被回复人是否要推送通知？这些业务逻辑会反过来锁死你的数据模型——嵌套还是引用，往往不是技术选型，而是权衡结果。
