modbus tcp报文必须手动解析mbap头和pdu，因workerman的onmessage仅提供原始字节流，需在连接对象维护缓冲区，先收齐7字节mbap头，再读length字段判断总长是否足够，不足则等待下一次数据到达。
Modbus TCP报文必须手动解析MBAP头和PDU
Workerman的onMessage只吐原始字节流，不会识别Modbus TCP帧结构。你看到的000100000006010300000002不是一整条消息，而是可能被TCP拆成两段送进回调——前6字节00010000和后6字节0006010300000002。不处理就直接unpack()会错位。
正确做法是：在连接对象上维护缓冲区，每次onMessage先追加$data，再检查是否收齐MBAP头（7字节）→ 读出Length字段（第5–6字节）→ 判断总长是否≥7 + Length → 不够就等下次，够了才截取完整帧。
- 事务ID和协议ID必须原样透传，用于匹配请求/响应
- Length字段值不含MBAP头本身，只含Unit ID + PDU长度
- 异常响应（如
0x83）也要解析，不能跳过——它说明寄存器地址越界或设备离线
Modbus RTU帧要校验CRC且不能用stream_socket_server直连
RTU走RS485串口，stream_socket_server('tcp://0.0.0.0:502')根本连不上。必须用php_serial扩展或fopen('/dev/ttyUSB0', 'r+b')，但阻塞式读会卡死Worker事件循环。
真实可行路径只有一条：用pcntl_fork启独立子进程，由它独占串口、做CRC校验、重试机制；主Worker进程只通过sysvmsg或Redis接收结果。别在onWorkerStart里fopen，失败不退出会导致整个服务假死。
- CRC校验必须在子进程内完成，错误帧（如CRC错、从站地址不匹配）立即丢弃
- RTU帧无长度字段，靠超时判断一帧结束：连续1.5字符时间无新字节即视为帧尾
- 串口设备路径必须绝对路径，且运行用户需在
dialout组：sudo usermod -a -G dialout www-data
Workerman自定义协议的input方法才是粘包解药
别再把所有逻辑堆在onMessage里拼接缓冲区。Workerman提供input钩子，在数据进入onMessage前就决定“这包齐不齐”。返回0表示不够，框架自动缓存；返回正整数表示可截取长度；返回false直接断连。
对Modbus TCP，典型input逻辑是：先读7字节MBAP头 → unpack('n', $head[4..5])得Length → 若strlen($buffer) 则return 0，否则return <code>7 + $length。
-
input函数必须声明为static，且不能有IO操作（如file_get_contents） - 如果硬件帧含校验和（如最后2字节），必须在
decode里校验，input只管长度 - 没实现
input就等于裸奔——粘包、断帧、内存泄漏全找上门
为什么不能用Timer::add轮询PLC？
有人写Timer::add(1, function() { $conn->send(...); });想每秒读一次寄存器，结果WebSocket延迟飙升、HTTP接口超时。因为send()后recv()是阻塞的，主线程卡住，整个事件循环停摆。
轮询必须异步：用AsyncTcpConnection发请求，靠onMessage收响应；或更稳妥地，让协议子进程自己定时轮询，主进程只消费结果。
- 每个设备连接应单独管理超时，避免一个PLC掉线拖垮全部采集
- Modbus TCP建议设
connect_timeout为3秒、read_timeout为5秒，超时后主动close连接 - 别信“多开几个Worker就能扛住”，串口和Modbus都是状态强依赖协议，资源争抢比想象中严重
真正难的不是解析那几行十六进制，而是把串口阻塞、TCP流式、协议状态机、进程隔离全拧在一起还不崩——任何一环漏掉超时、校验或清理，跑三天就内存溢出或连接堆积。别省那几行if ($len 。
