因为Symfony state-machine仅提供核心引擎，不自动绑定实体、持久化状态或处理错误，需手动配置状态图、指定property_path、显式flush到DB，并加数据库行锁防并发冲突。

State Machine 不是开箱即用的“集成即解决”方案，Composer 只负责安装依赖，状态机逻辑、转换规则、持久化和错误处理全得自己写。

为什么 composer require symfony/state-machine 后依然跑不起来？

因为 Symfony 的 state-machine 组件本身不包含实体绑定、数据库存储或事件监听器——它只提供核心引擎。你必须手动配置状态图（state_machine 配置块）、定义状态类、实现 StateMachineInterface 的使用逻辑。

• 常见错误现象：State machine "order" not found —— 忘了在 config/packages/framework.yaml 里声明该 state machine 名称
• 没定义初始状态（initial: 'created'），调用 $machine->can('confirm') 直接返回 false
• 状态字段名默认叫 currentState ，但你的实体属性是 $status，不配 property_path: 'status' 就永远不同步

如何让状态转换真正生效并保存到数据库？

State Machine 引擎默认只修改内存中的状态值，不自动 flush 到 DB。你必须显式触发持久化，且注意事务边界。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 典型做法：在调用 $machine->apply('confirm') 后，立刻执行 $entityManager->flush()
• 别在 Doctrine 事件（如 preUpdate）里调用 apply() —— 容易引发递归或状态不一致
• 如果用的是 MongoDB 或 Redis，需自定义 StateProviderInterface 和 StatePersisterInterface 实现
• 示例关键配置片段：

  state_machine:
    order:
      class: App\Entity\Order
      property_path: 'status'
      initial: 'created'
      states: ['created', 'confirmed', 'shipped', 'cancelled']
      transitions:
        confirm: { from: ['created'], to: 'confirmed' }
        ship: { from: ['confirmed'], to: 'shipped' }

状态冲突和并发修改怎么防？

多个请求同时对同一订单执行 confirm，可能绕过状态检查，导致非法跃迁或数据覆盖。

• 单纯靠 PHP 层 can() + apply() 无法保证原子性 —— 数据库行锁才是关键
• 推荐在 apply() 前加乐观锁：在实体中加 $version 字段，配合 Doctrine 的 @Version 注解
• 或改用数据库级状态校验：UPDATE ... WHERE status = 'created' AND id = ?，检查影响行数是否为 1
• 不要依赖前端传来的“当前状态”做判断 —— 攻击者可篡改请求参数绕过

状态机真正的复杂点不在配置语法，而在于状态语义的精确建模、跨服务的状态同步、以及失败后的一致性补偿。哪怕只是单体应用，apply() 调用的位置、异常分支是否 rollback、日志是否记录前状态——这些细节漏掉一个，线上就容易出现“卡在中间态”的订单。