真正稳的方案是单次查全+内存构树+引用挂载+根节点动态识别。需避免n+1查询、栈溢出、path歧义、children挂载失败及根节点识别错误等问题。
递归查库必踩的 N+1 和栈溢出坑
直接在递归函数里每次查子节点，等于把数据库当循环变量用。层级一深，SQL 就爆炸式增长，SELECT * FROM category WHERE parent_id = ? 被反复执行，连接数、内存、响应时间全崩。更危险的是环形引用（A→B→C→A）或 parent_id 指向不存在的 ID，PHP 不报错，但会一直调用直到 Fatal error: Maximum function nesting level of '256' reached 或超时。
实操建议：
- 一次性查全：
SELECT * FROM category ORDER BY parent_id, sort_order，结果转成 PHP 数组 - 构建父子映射表：
$map[$row['parent_id']][] = $row，避免每次递归都遍历全量数组 - 递归入口只传
$map和根$parentId = 0，函数内只操作内存，不碰数据库 - 加深度计数器，比如
if ($depth > 20) return []，防死循环
path 字段设计不当导致 LIKE 查询失效
很多人建 path 字段只存 "0/1/5" 或 "0,1,5"，然后用 WHERE path LIKE '0,1,%' 查子树——这会误命中 "0,10,105"；更糟的是字段类型设成 VARCHAR(255)，30 层分类一拼就截断，查不到后代。
实操建议：
-
path值统一加前后分隔符，存成",0,1,5,"（逗号）或"-0-1-5-"（短横线） - 查子树改用
WHERE path LIKE '%,1,%'或WHERE path LIKE '-0-1-%'，避开前缀歧义 -
path字段至少设为VARCHAR(512)，预留足够长度 - 必须给
path加索引：INDEX idx_path (path(50))，否则 LIKE 无法走索引
array_reduce 构树时 children 键挂载失败
有人想用 array_reduce 一行建树，结果返回空数组或子节点全丢——根本原因是没维护好引用，或没预占位。PHP 数组键不是按顺序来的，parent_id = 5 的节点可能出现在 id = 1 之前，$ref[$item['parent_id']] 还没初始化就被写入 children，直接静默失败。
实操建议：
- 先遍历一遍，确保每个
$ref[$item['id']]都存在：$ref[$item['id']] = &$item - 再遍历挂载：
$ref[$item['parent_id']]['children'][] = &$ref[$item['id']] - 根节点必须显式处理：
if (empty($item['parent_id'])) { $tree[] = &$ref[$item['id']]; } - 别依赖数组顺序，
parent_id可能大于当前id，预占位是硬性要求
根节点识别错误导致菜单缺一级
最常见现象：数据明明有 3 级，前端只渲染出 2 级。问题不在递归逻辑，而在根节点筛选条件写死了 parent_id == 0，但实际数据中根节点 parent_id 是 NULL、空字符串甚至 'root'，直接被过滤掉。
实操建议：
- 查数据前先确认真实根值：
SELECT DISTINCT parent_id FROM category - 判断用
empty($item['parent_id'])，兼容null、0、''、false - 构建树时，第一层必须显式从全量数组中捞出所有根，不能靠递归函数内部自动发现
- 返回结构统一用
'children' => []，避免前端取child或subs时 undefined
路径字段法更新成本高、易出错，递归法查库风险大——真正稳的方案，是单次查全 + 内存构树 + 引用挂载 + 根节点动态识别。这些细节不手动验证一遍，上线后问题一定出现在最晚被想到的地方。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
