单集合+parentid引用模式最稳妥，评论独立存储避免文档膨胀、性能下降和查询低效； parentid为null表示根评，需建索引；用$graphlookup展开树形结构并限制maxdepth；分页改用时间+id游标；树形节点需手动补全路径信息。
comments 集合用单集合 + parentId 引用模式，是最稳妥、可长期维护的选择。别嵌套进文章文档，也别搞多层数组嵌套。
为什么不能把评论直接塞进文章文档里？
看似省事，实际会拖垮性能和扩展性：
• 文章文档越来越大，每次更新标题、封面都要重写整个文档，触发写锁；
• 评论数一过几百，文档就接近16MB上限，MongoDB直接拒绝写入；
• 想查“某用户最近5条评论”，得遍历所有文章文档再过滤，没法建有效索引；
• 评论点赞、删除、编辑等操作，都变成对大文档的随机更新，IO压力陡增。
parentId 字段怎么设才不翻车？
所有评论（包括根评和回复）统一存进 comments 集合，靠 parentId 区分层级：
• 根评论： parentId: null 或 parentId: ObjectId("000000000000000000000000")（推荐用 null，语义清晰）；
• 回复： parentId 指向被回复那条评论的 _id；
• 必须建索引：db.comments.createIndex({"parentId": 1})，否则按父 ID 查子评就是全表扫；
• 如果常按文章查评论，再加一个复合索引：db.comments.createIndex({"articleId": 1, "createdAt": -1})。
要展开树形结构，别手写递归，用 $graphLookup
前端需要一次性拿到某篇文章的完整评论树（含多级回复），别发多次请求或在应用层递归拼装：
• 聚合管道里用 $graphLookup，指定 from: "comments"、startWith: "$_id"、connectFromField: "_id"、connectToField: "parentId"；
• 一定要设 maxDepth: 3（深度超 3 的回复通常折叠，没必要查）；
• 注意：它不支持跨集合关联，且深度每 +1，查询耗时大致翻倍；
• 如果只查一级回复，直接 find({$or: [{articleId: "xxx", parentId: null}, {parentId: {$in: [id1,id2]}}]}) 更快。
分页千万别用 skip，改用游标
热门文章下成千条评论，skip(1000) 会让 MongoDB 扫描前 1000 条再返回结果，越往后越慢：
• 改用时间 + ID 组合游标：查第一页传 {createdAt: {$lt: new Date()}, _id: {$lt: ObjectId("...")}}；
• 下一页就把上一页最后一条的 createdAt 和 _id 当作新条件；
• 这要求 createdAt 和 _id 在索引中顺序一致（比如 {"createdAt": -1, "_id": -1}）；
• 别忘了给 createdAt 单独建降序索引，否则游标失效。
$graphLookup 不提供这个，得靠应用层补或用 $addFields + $map 手动构造，一不小心就写出 O(n²) 聚合。
