TP6.0 巧用模型获取器格式化前端树形控件数据【Vue/React】

TP6.0 的模型获取器，说实话，很多人对它的理解还停留在“转状态文字”这个层面。其实它有个更实用的场景：在数据从模型里出来的时候，就把前端树形组件需要的那些字段“提前准备好”。这样一来，Vue 或 React 的 Tree 组件（比如 Element Plus 的 el-tree 或 Ant Design 的 Tree）拿到数据直接就能用，省去了前端反复映射、拼接、递归转换的麻烦。

用获取器统一处理树节点显示字段

树形控件通常要求数据有 label、value、children 这类固定字段。但问题来了，数据库里存的可能是 name、id、pid。与其在控制器里手动写个 foreach 去改键名，不如在模型里用获取器把这些“契约字段”定义好：

• 添加 getLabelAttr：返回 $this->name，或者带点前缀、后缀的格式化名称
• 添加 getValueAttr：直接返回 $this->id，保证和后端逻辑一致
• 添加 getDisabledAttr：根据 status 字段返回布尔值，控制节点是否可选

这样查出来的每个模型实例，天然就自带 label、value、disabled 这些属性。前端直接绑定就行，再也不用写一层 map 转换逻辑了。

用 append 动态注入 children 关系

TP6 默认查出来的是扁平数组（比如所有菜单项），但树组件需要的是嵌套结构。这里有个常见的误区：很多人直接在 PHP 层做递归组装，其实大可不必——那是后端过度干预前端渲染逻辑。更轻量的做法是：

• 先用 withAttr 或获取器，把单条记录的展示字段准备好
• 然后用 append(['children']) 告诉模型：“这个字段不存库，但我需要它”
• 在模型里定义 getChildrenAttr 方法，内部调用 self::where('pid', $this->id)->select()，自动挂载子节点

不过得注意，这种方式适合层级浅、数据量不大的菜单或分类场景。如果数据量一大，还是建议后端直接返回已经组装好的树形 JSON，避免 N+1 查询带来的性能问题。

配合 visible / hidden 控制输出字段

前端树组件往往只需要几个字段，多余字段传过去纯属浪费带宽。TP6 的 visible 和 hidden 方法正好能派上用场：

• $menu->visible(['label', 'value', 'disabled', 'children'])->toArray() —— 只暴露树所需字段
• $menu->hidden(['password', 'token', 'update_time'])->toArray() —— 隐私或冗余字段一键过滤

尤其是在返回整个菜单树时（比如 Menu::tree()->toArray()），配合获取器加上 visible，输出的就是一份开箱即用的前端树数据，结构干净、语义清晰、没有冗余。

前后端约定好字段，避免运行时判断

很多项目里，前端要写一堆 node.label || node.name || node.title 这样的兼容逻辑。根源在于后端没统一字段出口。TP6 的获取器正好可以成为这个“约定枢纽”：

• 所有树节点统一走 label 显示名、value 唯一标识、isLeaf 是否叶子节点（由 getIsLeafAttr 根据是否有子数据返回）
• 前端不再关心原始字段名，只认这几个“契约字段”
• 后续加图标、扩展属性（如 icon、href），也只在模型获取器里补，前端零改动

这种设计让前后端边界更清晰，也方便未来切换不同 UI 库（从 Element 切到 Arco、Naive），只要数据结构不变，树组件就能复用。