不能直接用 array_chunk() 切分类树数组做分页，因为无限极分类树是嵌套结构，array_chunk() 会强行拆散父子节点，导致某页缺失父级、渲染报错；必须先扁平化（推荐栈实现防循环）、再筛选、最后分页。
为什么不能直接用 array_chunk() 切分类树数组做分页
无限极分类树本质是嵌套结构（如递归生成的 $tree），不是扁平列表。直接对整个树数组调用 array_chunk() 会把父子节点强行拆开，导致某一页里只有子节点没父节点，前端渲染时丢失层级关系，甚至报 Undefined index: children 错误。
真正要分页的是「可展示的节点集合」——通常是所有叶子节点，或指定深度下的全部有效节点（比如只展示到三级菜单）。必须先展开、再筛选、最后分页。
- 先用递归或栈方式把树「扁平化」成带层级信息的线性数组，每个元素含
id、name、level、parent_id - 根据业务决定是否过滤（例如排除
status = 0的节点） - 再对这个扁平数组用
array_slice()分页，而非原树结构
如何安全地扁平化无限极分类树（兼容 MySQL 递归查询和 PHP 数组）
别硬写多层 foreach 嵌套。用栈（stack）比递归更可控，避免超栈或无限循环（比如存在脏数据：A→B→A 循环引用）。
$flat = [];
$stack = $rootNodes; // 一维数组，每个元素是 ['id'=>1, 'name'=>'首页', 'children'=>[...]]
while (!empty($stack)) {
$node = array_pop($stack);
// 记录当前节点（不含 children）
$flat[] = [
'id' => $node['id'],
'name' => $node['name'],
'level' => $node['level'] ?? 0,
'parent_id' => $node['parent_id'] ?? 0
];
// 把 children 压入栈（后进先出，保持原始顺序可用 array_unshift）
if (!empty($node['children'])) {
foreach (array_reverse($node['children']) as $child) {
$child['level'] = ($node['level'] ?? 0) + 1;
$child['parent_id'] = $node['id'];
array_push($stack, $child);
}
}
}注意：array_reverse() 是为了保证压栈后 pop 出来顺序与原始数组一致；如果业务要求严格按数据库 order 字段排序，应在查出原始树时就 order by，而不是靠 PHP 调整。
立即学习“PHP免费学习笔记（深入）”；
分页参数怎么传给前端才不丢层级上下文
用户翻到第 3 页，你只返回第 3 页的 10 个节点？不行。前端需要知道「这 10 个节点各自的父路径」才能渲染面包屑或折叠状态。所以分页响应里必须附带路径信息。
- 每个分页项额外加一个
path_ids字段，如[1, 5, 23]表示「首页→产品→手机」 - 或者返回最小公共祖先（LCA）ID，让前端按需加载父级（适合节点极多、网络敏感场景）
- 绝对不要只传
parent_id—— 用户点开第 5 页某个三级节点时，前端没法反向查出它的一级父类是谁
生成 path_ids 最好在扁平化阶段就完成，避免分页后再循环查库或遍历树：
// 扁平化时同步构建 path $node['path_ids'] = ($parentPath ?? []) + [$node['id']];
MySQL 层面提前分页（大数据量时必须考虑）
如果分类节点超过 10 万条，PHP 层扁平化+分页会吃光内存。这时得把分页逻辑下沉到 SQL，用递归 CTE（MySQL 8.0+）或闭包表（Closure Table）模型。
例如闭包表结构：category_closure 含 ancestor_id、descendant_id、depth。查「所有三级以内节点」并分页：
SELECT c.* FROM category c INNER JOIN category_closure cc ON c.id = cc.descendant_id WHERE cc.ancestor_id = 1 AND cc.depth BETWEEN 0 AND 3 ORDER BY cc.depth, c.sort_order LIMIT 20 OFFSET 40;
关键点：OFFSET 在闭包表上生效快，但要注意 depth = 0 是自身，别漏掉根节点；如果用 CTE，CTE 内不能带 LIMIT，必须外层套 SELECT 再分页。
实际项目中，树结构变动不频繁，建议生成扁平化缓存表（每天定时 job 更新），分页直接查缓存表，比实时计算稳得多。
