Eloquent 不支持属性层次结构或嵌套状态机，因其框架层仅提供基础字段操作、类型转换、访问器和生命周期钩子，不抽象业务语义；所谓层级需由状态字段、迁移规则与权限控制显式协同实现。
Eloquent 没有 Attribute Hierarchies 这个概念，也不存在“嵌套状态机”的内置支持；所谓层次结构必须由业务逻辑显式建模，靠状态字段 + 状态迁移规则 + 权限/可见性控制三者协同实现。
为什么 Eloquent 不支持属性层次结构或嵌套状态机
框架层只提供基础字段读写、类型转换（$casts）、访问器（getXXXAttribute）和生命周期钩子（creating/saving），不抽象“状态嵌套”“父子状态依赖”“层级流转约束”这类业务语义。如果你看到某段代码调用了 attributeHierarchies 或类似方法，基本可以确定是：自定义 Trait 未文档化、拼写错误（比如本意是 with() 预加载关联）、或把数据库的树形结构（如 parent_id）误称为“属性层次”。
真实项目中如何实现带层级的状态管理
典型场景如：订单有主状态（pending / shipped / delivered），而每个主状态下又分若干子状态（shipped → in_transit, shipped → out_for_delivery）。这不是靠 Eloquent 自动推导，而是靠以下组合：
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 数据库至少两个字段：
status（主状态，ENUM或TEXT）和sub_status（子状态，可空） - 模型里定义静态数组明确层级关系，例如：
public static function statusHierarchy(): array返回['shipped' => ['in_transit', 'out_for_delivery']] - 在
saving钩子里校验子状态是否合法：if (!in_array($this->sub_status, static::statusHierarchy()[$this->status] ?? [])) { throw new InvalidArgumentException('Invalid sub_status for status'); } - 用访问器封装读取逻辑：
public function getStatusLabelAttribute()返回合并标签（如 “已发货 · 运输中”），但注意它不参与查询 ——where('status_label', ...)会失败
避免把关联当层次，也别让访问器承担状态流转
常见错误是把父子模型（如 Category 和它的 parent() 关联）当成“属性层次”，然后在 getFullPathAttribute() 里递归拼接路径。这会导致 N+1、缓存失效、无法排序。更危险的是在访问器里触发状态变更（比如 getIsExpiredAttribute() 里调用 $this->expire()），违反读取无副作用原则。
立即学习“PHP免费学习笔记（深入）”；
- 状态流转必须显式调用方法，如
$order->ship()、$order->markAsDelivered()，并在方法内完成字段更新 + 日志记录 + 事件分发 - 需要“层级可见性”（如管理员能看到所有子状态，客服只能看当前主状态下的子状态）时，不要靠
appends控制，而应在资源类（OrderResource）或 API 响应构造时动态过滤字段 - 若真需树形状态（如多级审批流），建议用独立的状态机包（如
spatie/laravel-model-status），它把状态定义、迁移规则、权限检查都抽离为配置，而不是塞进 Eloquent 属性逻辑里
最容易被忽略的：状态字段的索引与查询性能
很多人只关注“怎么定义层次”，却忘了数据库层面的代价。用 status + sub_status 双字段组合查询时，如果没加联合索引，where status = ? and sub_status = ? 会全表扫描。别依赖 Eloquent 的链式调用掩盖底层低效 —— 在迁移里显式加索引：$table->index(['status', 'sub_status']);。另外，避免在 whereRaw 里拼接状态判断（如 "CONCAT(status, ':', sub_status) = ?"），这会让索引失效。
