“Eloquent Attribute Saga States”并非 Laravel 真实机制，是错误嫁接分布式 Saga 与 Eloquent 属性；应改用独立 Saga 协调器、专用状态字段及日志表，杜绝在访问器/修改器中实现跨服务状态流转。
“Eloquent Attribute Saga States”不是 Laravel 的真实机制，也没有对应包或官方支持——它属于对分布式 Saga 模式与 Eloquent 属性机制的错误嫁接。Laravel 模型层无法承载跨服务、长时间运行、可补偿的事务状态流转，强行用访问器、修改器或 $casts 模拟，只会导致状态不一致、补偿丢失、调试崩溃。
为什么不能用 accessor/mutator 实现 Saga 状态
常见错误是写一个 getSagaStateAttribute()，里面查 Redis 或调用远程服务判断“订单是否完成支付补偿”，再返回字符串；或者在 setSagaStateAttribute() 里自动触发补偿逻辑。问题直接暴露：
- 访问器不可控执行：每次
$order->saga_state都可能发起 HTTP 请求或 Redis 查询，批量渲染时变成 N+1 - 修改器绕过事务：赋值
$order->saga_state = 'compensated'不在数据库事务内，若后续 save() 失败，补偿已发但主状态未更新 - 无幂等保障：重复调用修改器可能多次发补偿请求，而 Saga 要求每步必须可重试、可跳过
- 无法回滚：Eloquent 没有 “undo this accessor side effect” 的能力，补偿失败后没有反向钩子
真正该用什么替代“Saga State”属性
把 Saga 当作**领域行为**，而非模型属性。状态存储和流程控制必须脱离 Eloquent 生命周期：
- 用独立 Saga 协调器（如自定义
OrderPaymentSaga类），封装initiate()、confirm()、compensate()方法，每个方法显式管理自身状态快照（存入saga_logs表） - 模型只保留轻量标识字段，如
saga_id（UUID）和saga_status（字符串枚举：pending/confirmed/compensated），用$casts = ['saga_status' => 'string']保证类型安全 - 状态变更必须走协调器，禁止任何地方直接改
$order->saga_status；模型中可加isSagaConfirmed(): bool这类只读方法，内部只查本字段，不触发副作用 - 补偿失败需记录到
saga_failures表，并由队列监听重试，而不是靠模型事件或观察器硬塞逻辑
数据库字段设计与迁移注意事项
saga_status 字段看似简单，但实际部署中容易踩坑：
立即学习“PHP免费学习笔记（深入）”；
- 不要用整数枚举：Saga 状态可能动态扩展（比如新增
timeout_recovered），整数映射难维护且不直观 - 必须加索引：
ALTER TABLE orders ADD INDEX idx_saga_status (saga_status);，否则查询待处理 Saga 会全表扫 - 避免和业务状态字段混用：不要让
status（订单主状态）和saga_status（支付子流程状态）互相覆盖或条件耦合，它们生命周期不同 - 迁移时设默认值：
$table->string('saga_status')->default('pending')->after('status');，防止旧数据 NULL 导致协调器逻辑分支爆炸
Saga 的核心是“外部可观测性”和“失败可追溯”，不是让模型看起来像有状态机。一旦开始往 getXXXAttribute 里塞 HTTP 客户端或 DB 事务，就说明已经偏离了 Saga 的设计初衷——它从来不是属性，而是跨边界的契约流程。
