用 parent_id 实现单层嵌套最稳：只需添加可空 unsignedbiginteger 类型的 parent_id 字段并建索引，根评论 parent_id 为 null，二级回复指向父 id；配合 with 预加载 user 和 parent.user 避免 n+1；返回扁平数组带 depth 和 is_root 字段；软删除需排除已删 parent，并用外键 on delete set null 保障一致性。
用 parent_id 实现单层嵌套最稳
Laravel 做评论嵌套，第一反应不是树形结构或闭包表，而是加个 parent_id 字段——它够轻、够快、兼容性好，90% 的场景（比如二级回复）根本不需要更重的方案。
常见错误是直接上 lft/rgt 或递归关联，结果查一条评论要 JOIN 五六次，分页都崩。实际只要让评论表带一个可空的 parent_id（类型 unsignedBigInteger），再加个索引就行：
Schema::table('comments', function (Blueprint $table) {
$table->unsignedBigInteger('parent_id')->nullable()->index();
});
-
parent_id = null表示根评论（一级） -
parent_id = 123表示这是 ID 为 123 的评论的直接回复（二级） - 不支持三级及以上嵌套？多数产品压根不需要，强行支持反而拖慢列表渲染和数据库查询
Laravel 关联怎么写才不 N+1
评论列表里要显示“这条回复是谁发的”“原评论内容是什么”，但一写 belongsTo 就触发 N+1。关键不是关掉 Eager Loading，而是选对加载策略。
典型错误：在循环里调用 $comment->parent->user->name，或者只写 with('user') 却漏了 parent 和 parent.user。
- 查根评论时，用
with(['user', 'replies' => fn ($q) => $q->with(['user', 'parent.user'])]) -
replies是你定义的hasMany关联，指向parent_id字段 - 如果只查某条评论的所有后代（比如展开全部回复），别用递归关系，改用
whereRaw('path LIKE ?'或临时查两次：先取 ID 树，再按 ID 批量查
前端渲染时怎么判断层级和折叠逻辑
后端不拼 HTML，但得给前端足够明确的结构信息。很多人传个二维数组完事，结果前端算缩进、处理折叠状态全靠猜。
错误做法：返回 ['replies' => [...]] 嵌套死循环，前端递归渲染卡顿，还无法做懒加载。
- 后端统一返回扁平数组，每项带
depth（计算方式：0是根，1是直接回复，最多到2） - 加个
is_root布尔字段，比判断parent_id === null更直觉 - 需要折叠时，前端只收
depth = 0和depth = 1的数据，点“查看回复”再拉depth = 2的子集（用comment_id当参数）
软删除 + 嵌套评论的坑在哪
开了 SoftDeletes 后，parent_id 指向一条已软删的评论，会导致 parent 关联查不到数据，但又不报错——页面上就突然少了一段“回复自：xxx”，很隐蔽。
这不是 Laravel 的 bug，是设计没对齐：软删应该连同它的子评论一起不可见，而不是让子评论“悬空”。
- 查评论列表时，必须加
whereDoesntHave('parent', fn ($q) => $q->onlyTrashed()) - 删除根评论前，先用
where('parent_id', $id)->update(['parent_id' => null])把子评论降级，否则它们会永远丢失上下文 - 不要依赖模型事件自动清理子评论，事务失败时容易漏；用数据库外键的
ON DELETE SET NULL更可靠
嵌套深度超过两级时，路径存储、排序、分页的代价会指数上升，而用户真实交互中极少展开三层以上。把“无限”当设计目标，不如先守住二级的稳定性和响应速度。
