应避免递归，改用迭代+栈模拟：将节点ID压入数组，循环取并查子节点追加，控制单次SQL行数，禁用N+1查询，预加载需显式约束层级。
Webman中递归构建树形结构时内存溢出怎么办
Webman本身不内置树形结构处理逻辑，但高频递归（比如无限级分类、组织架构）容易在PHP-FPM或Worker进程里触发内存限制。关键不是“怎么写递归”，而是“怎么避免递归”。
- 用
with()预加载替代N+1查询：ThinkORM支持with(['children'])，但必须配合where('parent_id', $id)显式约束层级，否则会拉全表 - 禁止在
foreach里嵌套DB::table()->where('parent_id', $item['id'])->get()——这是最常见内存爆炸源头 - 改用迭代+栈模拟递归：把待处理节点ID压入数组，每次
array_shift()取一个，查其子节点并追加到栈尾，避免PHP调用栈深度累积 - 设置
ini_set('memory_limit', '256M')只是掩耳盗铃，真正要控制的是单次SQL返回行数，建议用limit 1000分批处理
如何用Webman的事件机制解耦树节点变更通知
当某节点被移动或删除，下游服务（如缓存、搜索索引、权限继承）需要感知。硬编码回调易导致耦合和事务不一致，Webman的Event::emit()是更轻量的选择。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 触发点只在模型
save()或delete()后 emit'node.moved'或'node.deleted'，传参仅含node_id和old_parent_id - 监听器注册在
app/Listener/TreeChangedListener.php，用Redis::del("tree:{$node_id}")清缓存，而非直接调用Cache::delete()——避免阻塞主流程 - 不要在监听器里做耗时操作（如HTTP请求），改用
Worker::$process->async()丢进异步进程池 - 注意事件命名空间：避免用
'tree.*'这种宽泛通配，精确到'tree.category.moved'，防止误触发
TreeBuilder类封装后如何适配不同业务字段名
电商类目用cat_id/pid，组织架构用dept_id/leader_id，强行统一字段名会破坏领域语义。解决方案是参数化映射，而非继承重写。
- 构造函数接受配置数组：
new TreeBuilder(['id_field' => 'dept_id', 'parent_field' => 'leader_id', 'root_value' => 0]) - 内部不硬编码
$row['parent_id']，全部通过$this->config['parent_field']动态取值 - 排序字段也参数化：
'order_field' => 'sort_order'，默认用'sort'，避免前端传错字段名导致ORDER BY失效 - 扁平转树时，用
array_column($data, $this->config['id_field'])代替array_column($data, 'id')，否则空数组无声失败
为什么用Redis缓存树结构反而变慢
缓存树结构本意是提速，但若序列化方式或键设计不当，反而比直连MySQL还慢。问题常出在序列化粒度和反序列化开销上。
- 别用
serialize()存整棵树——PHP反序列化比json_decode()慢3倍以上，且无法被其他语言消费；改用json_encode($tree, JSON_UNESCAPED_UNICODE) - 缓存键别用
"tree:all"这种粗粒度键，按根节点拆分："tree:category:1"、"tree:dept:100"，避免单个节点更新导致全树缓存失效 - 设置过期时间要带随机偏移：
3600 + rand(0, 600)，防止缓存雪崩 - 读缓存时用
Redis::get()+json_decode()，别用Cache::get()——后者可能触发额外的序列化/反序列化层
parent_id和path字段，必须包裹在DB::transaction()里，而Webman默认不开启事务，得手动加。 
