用一次查询获取全部评论并用id建立映射，再遍历组装children数组，仅取parent_id为0的作为根节点；需校验parent_id存在性、初始化children字段、防止循环引用和深度溢出。
怎么用 PHP 递归把平铺评论变成嵌套树
直接说结论：用一次数据库查询 + 递归函数组装，别在循环里查数据库。否则 100 条评论可能触发上百次查询，页面直接卡死。
常见错误是写个 foreach，每遇到一个 parent_id 不为 0 的评论，就去查它的父级——这叫 N+1 查询，性能灾难。
- 先用
SELECT * FROM comments ORDER BY id拿全量数据（注意别漏id和parent_id） - 把结果转成数组，用
id做键存一遍：$map[$row['id']] = $row - 再遍历一遍，对每个
parent_id > 0的项，用$map[$row['parent_id']]找到父节点，塞进它的children数组里 - 最后只取
parent_id == 0的那些作为根节点
为什么不能用 MySQL 自带的递归 CTE（比如 WITH RECURSIVE）
PHP 7.4 之前很多生产环境还跑着 MySQL 5.6/5.7，根本不支持 WITH RECURSIVE。强行用，部署时直接报错 ERROR 1064。
即使你用的是 MySQL 8.0+，CTE 在评论场景下也容易翻车：深度嵌套时会触发 cte_max_recursion_depth 限制，默认 1000，但实际评论链 rarely 超过 5 层；真正问题是它没法和 PHP 的分页、排序、权限过滤自然衔接——你得在 SQL 里把用户可见性逻辑全写进去，维护成本飙升。
立即学习“PHP免费学习笔记（深入）”；
- CTE 返回的是扁平结果，PHP 层仍需二次组装树，没省多少事
- 如果要按「最新回复时间」排序整个树，CTE 很难优雅实现
- 多数 CMS 或框架（如 Laravel）的 Eloquent 默认不生成 CTE，得手写原生 SQL，破坏抽象层
递归函数里 children 字段怎么安全初始化
很多人直接写 $comment['children'] = []，但没检查 $comment 是不是数组，或者字段是否已存在，导致 Notice 错误或覆盖原始数据。
更麻烦的是：如果某条评论的 parent_id 指向一个根本不存在的 ID（比如被删了），你的递归会静默失败，那条评论就丢了，连日志都不报。
- 初始化前加判断：
if (!isset($comment['children'])) $comment['children'] = [] - 往父节点塞子项前，先确认
isset($map[$comment['parent_id']])，不满足就跳过或记录告警 - 别用引用传递搞乱原始数据，
buildTree($comments)应该返回新结构，原数组保持不变 - 示例片段：
$tree = [];<br>foreach ($comments as $c) {<br> if ($c['parent_id'] == 0) {<br> $tree[] = $c;<br> } else {<br> if (isset($map[$c['parent_id']])) {<br> $map[$c['parent_id']]['children'][] = $c;<br> }<br> }<br>}
前端渲染时怎么避免无限递归崩溃
后端递归没问题，但前端用 Vue/React 渲染嵌套评论时，如果没设深度限制，遇到恶意构造的循环引用（比如 A 的 parent_id 指向 B，B 又指回 A），JS 调用栈直接爆掉，页面白屏。
这不是 PHP 的锅，但你得提前防住——在 PHP 组装树时加一层深度校验，超过 10 层就截断，并打日志。
- 递归函数里传入当前层级参数，每次 +1，>= 10 就 return []
- 数据库加约束：
parent_id不能等于自身id（用 CHECK 约束或应用层拦截） - 前端模板里也加
v-if="depth 类似的保护，双保险 - 别信前端传来的
parent_id，后端必须验证它是否真实存在且非祖先
最常被忽略的是循环引用检测——光查是否存在不够，还得做拓扑判断。简单做法：组装过程中维护一个路径数组，发现重复 id 就中止该分支。
