Webman本身不提供ERP流水线管理能力，所有业务逻辑需自行设计并注入控制器或服务层；应通过状态机+事件驱动+显式事务控制组织流水线，避免中间件承载核心状态跃迁，使用独立Service类封装原子环节，关键变更写入pipeline_log表并带trace_id，禁用全局静态缓存，显式指定数据库连接，日志采用Monolog按trace_id切分，压测真实路径防阻塞。
Webman 本身不提供 ERP 流水线管理能力，它只负责高性能 HTTP 服务承载和请求调度；所有业务逻辑（如 BOM 展开、MRP 计算、工单状态流转、多级审批链）必须由你自行设计并注入到 Webman 的控制器或服务层中。
Webman 中如何组织 ERP 流水线的业务逻辑层
流水线不是靠框架自动跑起来的，而是靠你定义状态机 + 事件驱动 + 显式事务控制。常见错误是把所有校验和更新写在同一个 Controller 方法里，导致不可回滚、难测试、无法重试。
- 用独立的
ProductionPipelineService类封装整条流水线，每个环节（如validateBom()、reserveMaterial()、createWorkOrder()）作为原子方法，返回明确的成功/失败结构 - 避免在流水线中直接调用
DB::transaction()全局包裹——不同环节可能需要不同隔离级别，比如库存锁定用SELECT FOR UPDATE，而日志记录可走异步队列 - 关键状态变更（如工单从“待排产”→“已下发”）必须写入
pipeline_log表，并带上trace_id，否则线上排查卡点时只能靠猜 - 不要复用 Laravel 的
Job或 ThinkPHP 的Task模式——Webman没有内置队列驱动，需显式集成redis或amqp客户端，并手动处理失败重试与幂等
为什么不能直接用 Webman 的中间件做流水线拦截
中间件适合统一鉴权、日志、跨域，但不适合承载 ERP 流水线的核心状态跃迁逻辑。典型问题是：中间件无法感知上一环节是否成功，也无法决定是否跳过后续环节。
-
Webman中间件执行顺序固定且不可中断（除非抛异常），而 ERP 流水线常需“条件跳过”，例如：紧急插单时跳过产能校验，但保留物料齐套检查 - 中间件无法访问当前流水线实例上下文（如
$pipeline->getStep('material_check')），所有判断都得靠全局变量或 Session，极易引发并发冲突 - 调试困难：你在
app/middleware/CheckCapacity.php里加了var_dump，结果发现它在工单创建前就被执行了三次——因为路由匹配、参数解析、权限校验各触发一次
Webman 下实现带分支与回退的流水线示例
一个真实的生产工单下发流程可能包含并行校验（BOM有效性 + 库存可用性）、条件分支（是否启用自动排程）、人工干预节点（计划员确认）。下面是一个可落地的结构示意：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
// app/service/ProductionPipeline.php
class ProductionPipeline
{
public function execute(array $input): array
{
$this->traceId = uniqid('pl-', true);
// Step 1: 解析输入并初始化上下文
$context = $this->initContext($input);
// Step 2: 并行执行两个校验（用协程或同步，依场景定）
$bomOk = $this->validateBom($context);
$stockOk = $this->checkStock($context);
if (!$bomOk || !$stockOk) {
return ['status' => 'failed', 'reason' => 'bom_or_stock_invalid'];
}
// Step 3: 条件分支：是否启用 APS 自动排程
if ($context['use_aps']) {
$scheduleResult = $this->callApsApi($context);
if (!$scheduleResult['success']) {
// 回退到人工排程节点，不终止流水线
$context['need_manual_scheduling'] = true;
}
}
// Step 4: 创建工单主记录（此时才真正写 DB）
$woId = $this->createWorkOrder($context);
// Step 5: 异步触发下游（如通知 MES 接收工单）
$this->dispatchToMes($woId, $context);
return ['status' => 'success', 'work_order_id' => $woId];
}
}
注意：callApsApi 必须设置超时（建议 ≤3s），否则会拖垮整个 Webman 进程；dispatchToMes 必须确保至少一次投递（推荐用 Redis List + ACK 机制，而非直连 HTTP）。
Webman 部署时流水线性能容易被忽略的点
Webman 常驻内存特性是一把双刃剑：代码加载快，但全局变量或静态属性一旦污染，就会在多个请求间残留状态，导致流水线行为错乱。
- 禁止在 Service 类里用
static $cache = []缓存 BOM 展开结果——不同租户、不同版本 BOM 会混在一起 - 所有数据库连接必须显式指定
connection名称（如mysql_production），不能依赖默认连接，否则测试环境和生产环境可能共用连接池，引发锁等待 - 日志输出别用
error_log()，它在多进程下会乱序；改用Monolog+RotatingFileHandler，并按trace_id切分文件 - 上线前务必压测真实流水线路径（如并发 50 工单创建），观察
Webman主进程 CPU 是否持续 >80%，若是，说明某环节存在阻塞 IO（比如没设 timeout 的 cURL 调用）
流水线越复杂，越要克制“全放一个请求里做完”的冲动。真正的高可靠，来自可拆解、可监控、可补偿的设计，而不是靠框架自动兜底。
