递归查库易爆栈超时，应先查全量数据构建父子映射表再内存递归；path字段需加前后逗号防误匹配，长度至少VARCHAR(512)；array_reduce建树必须用引用并预占位；JSON输出前需清洗非标量值。
递归查数据库时容易爆栈或超时
PHP 默认递归深度没硬限制，但实际执行中会受 memory_limit 和 max_execution_time 卡住，尤其分类表过万行、层级超 10 层时，一次全量递归查库几乎必挂。
实操建议：
- 不要在递归函数里反复查数据库，先用一条 SELECT * FROM category ORDER BY parent_id, sort 拿全量数据到 PHP 数组
- 用「父子映射表」预处理：遍历一遍数据，构建 $map[$parent_id][] = $row
- 递归只操作内存数组，函数签名类似 buildTree($map, $parentId = 0)
- 加个深度计数器，超过 20 层直接 return [] 防死循环
path 字段设计与查询陷阱
用 path 字段（如 "0,1,5,12"）存祖先链，查子树快，但更新成本高、路径拼接易出错。
常见错误现象：
- WHERE path LIKE '0,1,%' 匹配到 "0,10,105" 这种误匹配
- 插入新节点时漏补全父级 path，导致子树查不出来
- path 字段类型用 VARCHAR(255)，但深层级路径超长被截断
实操建议：
- path 值统一用固定分隔符（推荐英文逗号），开头结尾都加，变成 ",0,1,5,"
- 查询子树改用 WHERE path LIKE '%,1,%'，避免前缀歧义
- 新增节点前，先 SELECT path FROM category WHERE id = ? 拿父级 path，再拼接
- path 字段至少设为 VARCHAR(512)，预留 30 层 × 平均 ID 长度空间
array_reduce + 引用构造树的坑
有人想用 array_reduce 一行搞不定树结构，结果返回空数组或键错乱——根本原因是没正确维护引用关系。
使用场景：已有扁平数组（含 id、parent_id），需转成嵌套数组，且要求 O(n) 时间复杂度。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 必须用引用方式存节点：$ref[0] = &$treeRoot;，否则子节点无法挂载
- 每次遍历时，先确保 $ref[$item['parent_id']] 存在，再把当前项塞进它的 children 数组
- 不要依赖数组顺序，parent_id 可能比 id 大，得先扫一遍建好所有 $ref[$id] 占位符
- 示例关键片段：
$ref = []; $tree = [];
foreach ($list as $item) {
$ref[$item['id']] = &$item;
$ref[$item['parent_id']]['children'][] = &$ref[$item['id']];
}
JSON 输出时无限递归报错
直接 json_encode($tree) 报 "Nesting level too deep"，不是因为层级真那么深，而是对象/资源/闭包混在了数组里没清理干净。
性能影响：PHP 7.4+ 对深度检测更敏感，即使只有 15 层，若某节点带 mysqli_result 或未 unset 的临时属性，也会提前中断。
实操建议：
- 构建树后，用 array_walk_recursive 清洗掉非标量值：if (!is_scalar($v)) { $v = null; }
- 或更稳妥：用 json_encode($tree, JSON_INVALID_UTF8_SUBSTITUTE) 避开编码问题
- 如果树里存了模型对象，必须显式调用 toArray() 或定义 JsonSerializable 接口
- 调试时加一句 echo count($tree, COUNT_RECURSIVE); 看实际嵌套元素总数，超 5000 就该分页或懒加载
事情说清了就结束。真正难的不是写对那几行递归，是想清楚：这棵树谁查得多、谁改得多、要不要支持移动整棵子树、前端是否需要展开状态持久化——这些决定 path 还是 closure table，而不是 PHP 函数怎么写。
