Workerman不能直接调度AGV，因其仅为异步通信框架，不提供路径规划、交通管制、地图建模及运动控制等核心调度能力；它仅作为VDA5050等协议的可靠消息中转中枢，需与专用调度引擎协同工作。
Workerman 本身不能直接调度 AGV 小车，它只负责可靠收发指令和状态；真要控制小车，你得在 Workerman 之上接协议层（如 VDA5050、Modbus TCP）或硬件驱动，否则发出去的只是“空气消息”。
为什么不能直接用 Workerman 做 AGV 调度核心？
Workerman 是一个 PHP 的异步 I/O 框架，擅长长连接管理、高并发消息中转，但它不提供：路径规划算法、交通冲突检测、地图建模、AGV 底层运动控制。这些必须由专用模块承担。Workerman 在这里的真实角色是「通信中枢」——把 WMS 下发的订单、AGV 上报的状态、仿真系统发来的测试数据，在不同进程/服务间低延迟、不丢包地流转。
- 常见错误现象：
onMessage里直接写$agv->moveTo(12, 34)，结果报错Call to undefined method—— 因为 PHP 没有原生 AGV 驱动类 - 正确做法：Workerman 收到任务后，把
{"agv_id":"AGV_001","order_id":"ORD-789","node":"CHARGE_STATION"}转发给独立的调度引擎（如用 Python 写的路径规划服务），再把引擎返回的轨迹点数组下发给对应 AGV - 性能影响：若在
onWorkerStart里加载大型地图 JSON 或初始化 ROS 节点，会导致 Worker 进程启动卡顿甚至超时退出
Workerman 如何对接 VDA5050 协议？
VDA5050 是当前跨品牌 AGV 协作的事实标准，Workerman 可作为其 HTTP/WebSocket 网关。关键不是“实现协议”，而是“不做多余解析”——把原始 JSON 透传给业务层。
- 必须保留字段：
header中的manufacturer、serialNumber，state中的batteryState、position，调度系统靠这些做车辆筛选和电量预警 - 推荐结构：用
Worker监听8080（HTTP 接收 VDA5050state上报），另起一个WebsocketWorker监听8081（推送order指令），避免阻塞 - 容易踩的坑：VDA5050 要求
state消息每 500ms 至少上报一次，但 Workerman 默认onMessage不保证时序；需用Timer::add主动触发心跳，而不是依赖客户端上报
如何让 Workerman 和 PLC/IO 设备通信？
工厂现场大量依赖西门子 S7、三菱 Q 系列 PLC 控制路口信号灯、升降机、安全光栅，Workerman 需通过 Modbus TCP 或 S7Comm 协议读写寄存器。
- 不要用纯 PHP 实现 S7Comm —— 协议复杂且无官方库，推荐调用已验证的 CLI 工具：
php exec('s7comm-cli -d 192.168.1.100 -r DB1,0,4 -t int') - 更稳方案：用 Workerman 做消息代理，实际通信由 Go/Python 编写的轻量服务完成（例如用
gopcua对接 OPC UA 服务器），Workerman 只管 JSON 格式转换和重试逻辑 - 兼容性注意：Modbus TCP 的
function code 0x03（读保持寄存器）在某些国产 PLC 上需加 1 字节 padding，否则返回IllegalFunction错误
真实部署时最易被忽略的点
Workerman 进程在 Docker 容器里跑得飞快，但一上生产环境就掉连接——问题往往不在代码，而在网络策略和信号处理。
- Linux 内核参数：
net.core.somaxconn必须 ≥ 65535，否则高并发下accept()失败，AGV 状态批量断连 - Docker 配置：必须加
--init参数，否则 Workerman 的子进程（如调用s7comm-cli）会变成僵尸进程，内存缓慢泄漏 - 日志陷阱：不要用
file_put_contents写日志，高频写入会阻塞事件循环；改用Worker::$stdoutFile = '/var/log/workerman-agv.log'让主进程统一刷盘
