优先选用laravel-wf（规则驱动型流程）或venture（任务依赖型异步链）；laravel-wf将流程全实体化为eloquent模型，支持orm操作与状态机钩子，适合审批类业务；venture基于队列与显式依赖声明，适合订单处理等异步任务链。
直接上结论：别自己从零写状态机，优先用 laravel-wf 或 Venture，它们分别解决「规则驱动型流程」和「任务依赖型异步链」两类核心场景——选错方案会导致后期维护成本翻倍。
laravel-wf 适合审批类、状态流转明确的业务流程
当你需要处理请假、采购、立项这类有固定节点、多人参与、需记录完整轨迹的流程时，laravel-wf 是更贴近 Laravel 开发习惯的选择。它把流程定义、实例、任务全封装成 Eloquent 模型，直接用 ORM 操作，不碰 XML/JSON 配置文件。
- 流程定义必须用
ProcessDefine::create()创建，content字段是 JSON 格式的节点数组，注意id值要全局唯一且不能含特殊字符（如空格、点号），否则引擎解析失败 - 启动实例时传参要用
Dict对象（不是普通数组），否则args无法透传到后续节点；常见错误是直接传['user_id' => 123]导致变量丢失 -
wf_process_instance表里的state字段是整型枚举值，不是字符串，查“进行中”得用ProcessInstanceStateEnum::RUNNING，硬写'running'会查不到数据 - 权限控制靠
ProcessTaskActor关联，但分配逻辑不在模型层自动触发，需手动调用ProcessTaskService::assignActor()，漏掉这步任务就没人能看见
Venture 更适合订单处理、数据清洗等异步任务链
如果你的“工作流”本质是一串有先后依赖、可能失败重试、需要监控进度的后台作业（比如库存检查 → 支付验证 → 订单确认），Venture 的设计更自然。它基于 Laravel 队列，每个 Job 是独立可测试的类，依赖关系写在 PHP 代码里，调试友好。
- 依赖必须显式声明，例如
->addJob(new 支付验证(), [库存检查::class])，漏写方括号或类名字符串（如写成'库存检查'）会导致依赖不生效，任务并行执行而非串行 - 条件依赖要用
withDependenciesIf()，回调函数里不能访问外部变量（闭包作用域限制），想传参数得提前绑定到 job 实例属性上 - 失败重试由队列配置驱动，但
Venture的max_retries和 Laravel 队列的tries是两套机制，必须同时配，否则重试次数不一致 - 工作流状态（
running/failed）存在venture_workflows表，但不会自动同步到业务表，需自己监听WorkflowFinished事件来更新订单状态
别踩 ORM 与流程引擎耦合的坑
很多团队试图用 Eloquent 模型 + 状态字段 + 手动 if-else 实现流程，短期快，长期难维护。真正复杂的地方不在“怎么跑”，而在“怎么回滚”“怎么挂起”“怎么查历史分支”。laravel-wf 内置了状态机钩子（如 onStateChange），Venture 提供了 Workflow::cancel()，这些能力自己补成本极高。
- 不要在
ProcessInstance模型里加业务字段（如order_id），应通过business_no关联，否则迁移或版本升级时字段冲突 -
Venture的 job 类不能依赖容器中 request 相关服务（如Request、Session），因为运行在队列进程里，无 HTTP 上下文 - 两个方案都不支持跨数据库事务：流程状态更新和业务数据更新若在不同库，需用最终一致性+补偿事务，不能指望引擎自动保证
最易被忽略的一点：流程引擎不是银弹。laravel-wf 处理的是“人驱动”的流程，Venture 处理的是“机器驱动”的任务链。混用或强行嫁接，往往比选一个坚持用到底更费劲。
