Webman 适合做 ERP 的高性能 API 层和实时通信层，而非全栈业务层；它专精于订单同步、库存扣减、设备上报等毫秒级响应模块，不处理 RBAC 渲染、表单构建或工作流引擎，需与 Yii3-RBAC、Camunda、Vue Admin 等协同补足四大支柱能力。
Webman 适合做 ERP 的哪一层？
它不是 Laravel 那种“开箱即 ERP”的全栈框架，而是专精于高性能 API 层 + 实时通信层。真实落地中，Webman 最常承担的角色是：订单同步服务、库存扣减网关、设备状态上报接收器、多租户路由分发中间件。它不处理复杂的 RBAC 规则渲染，也不内置表单构建器或工作流引擎——这些得靠上层业务系统补足。
常见错误现象：Class 'app\controller\UserController' not found，本质是开发者误把 Webman 当成 ThinkPHP 那类 MVC 框架来用，硬套传统控制器路由结构，却忽略了它的核心设计是“事件驱动 + 协程调度”。
- 适用场景：ERP 中需要毫秒级响应的模块，比如扫码入库、产线报工、实时库存预警
- 不适用场景：后台管理界面、审批流配置页、多级组织架构树形编辑器
- 参数差异：
config/server.php中的worker_num建议设为 CPU 核心数 × 2，而非照搬 Laravel 的max_connections思维
怎么补足 Webman 缺失的 ERP 能力？
Webman 自身轻量，但企业 ERP 必须有权限、流程、单据、报表四大支柱。不能靠它单打独斗，得明确分工：
- 权限控制交给
yii3-rbac或自建策略中心，Webman 只做 token 校验和路由拦截 - 流程引擎用
camunda或国产flowable，Webman 仅作为流程触发与回调的 HTTP 网关 - 单据模板用
laravel-nova或vue-admin-template前端渲染，Webman 提供/api/v1/invoice/{id}这类原子接口 - 报表导出走
phpspreadsheet+redis queue异步生成，Webman 负责投递任务并轮询状态
性能影响：若强行在 Webman 中集成 Doctrine ORM 或复杂视图渲染，协程调度会被阻塞，RPS 从 31 倍跌回接近 ThinkPHP 水平——这不是框架问题，是职责错配。
部署时最容易被忽略的三个细节
Webman 常驻内存特性带来性能优势，也放大了配置失误的影响：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
-
config/autoload/processes.php中的子进程未设置reloadable => false，导致定时任务（如日结库存）在热更新时重复执行 - Redis 连接未启用
pconnect，协程复用连接池失效，高并发下出现Connection refused - 日志写入用了
file_put_contents同步方式，而不是Monolog\Handler\StreamHandler+BufferHandler，造成 I/O 阻塞协程
信创环境特别注意：workerman 在麒麟 V10 SP3 上需手动编译 ext-event 扩展，否则 event-loop 降级为 select，吞吐量损失超 40%。
要不要用 Webman 替代现有 ERP 的某个模块？
答案取决于你手里的 ERP 是什么架构。如果是传统单体 PHP ERP（如早期 ThinkPHP 版），用 Webman 替换其 warehouse 模块最稳妥——只需暴露 /api/stock/check 和 /api/stock/deduct 两个接口，前端不变，后端替换，风险可控。
但如果 ERP 已是微服务架构（比如用 Hyperf 做订单中心、Laravel 做财务中心），Webman 更适合作为新接入的 IoT 设备接入层，而非替换已有服务——它的价值不在“替代”，而在“补位”。
真正卡住落地的，从来不是性能数字，而是业务字段语义对齐。比如 ERP 里“可用库存”在 Webman 接口里叫 available_qty，但在 MES 系统里叫 on_hand_free，这种映射必须在网关层显式定义，不能指望文档或口头约定。
