symfony工作流组件仅校验并执行合法状态迁移，不存状态、不管权限、不改数据库；需正确安装、严格配置workflow.yaml、字段名与marking_store一致、状态定义完整、迁移必用apply()、事件监听须带workflow前缀。
Symfony 工作流组件不是“设好就自动跑”的黑盒，它专注做一件事：校验状态迁移是否合法，并执行迁移动作。它不存状态、不管权限、也不改数据库——这些都得你来写。用对了很轻巧，用错了连报错都没有，状态卡住还查不出原因。
装组件和配文件是两道硬门槛
光 composer require symfony/workflow 不够，还得确保 config/packages/workflow.yaml 文件存在且路径完全正确（不能叫 workflows.yaml 或 workflow.php）。配置必须以 framework: → workflows: 开头，每个 workflow 必须显式声明 type: state_machine（多数业务只需单状态）。
- 漏写 type，会报 “The workflow 'xxx' has no type defined”
- 文件名或顶层键名错一个字母，容器里根本不会注册 workflow 服务
- 实体类字段名必须和 marking_store.arguments 里写的完全一致，比如写了 arguments: ['status']，那实体就得有 public string $status = 'draft';
状态定义要完整且匹配业务直觉
places 是所有可能状态的集合，transitions 描述谁能从哪到哪，initial_place 指定起点。from 可以是数组（如 archive 允许从 published 或 review 进入），但 to 必须是单个字符串——state_machine 不支持一转多。
- places 缺少某个实际用到的状态（比如忘了加 'rejected'），调用 can() 就会返回 false
- initial_place 值必须在 places 列表里，否则启动时无法标记初始状态
- 状态名建议全小写、下划线分隔（如 'in_review'），避免大小写混用引发静默失败
触发迁移必须走 apply()，别手改属性
直接写 $article->setState('published') 看似省事，实则绕过全部校验：can() 判断失效、事件监听收不到、审计日志断档。真正生效的只有一行：
- $workflow->apply($article, 'publish');
- 执行前建议先用 $workflow->can($article, 'publish') 预检，避免抛出 LogicException
- apply 成功后，记得手动 $entityManager->flush() 把新状态写进数据库
事件监听要按命名规范写
Workflow 发出的事件名是固定的，比如状态变更前触发 workflow.entered，迁移成功后是 workflow.completed。监听器服务需打上对应 tag：
- YAML 中写 tags: [{ name: 'kernel.event_listener', event: 'workflow.article_publishing.entered' }]
- 方法参数必须是 WorkflowEvent 类型，从中取实体和 transition 名称
- 别指望 'workflow.entered' 这种泛义名能捕获所有 workflow，必须带具体 workflow 名前缀
不复杂但容易忽略：装对包、配对路径、字段名对齐、迁移走 apply、事件带前缀——四点齐了，状态机才算真正转起来。
