不能直接用timer::add轮询串口设备，因其阻塞式i/o会拖住worker进程，导致定时任务、websocket和http全部延迟；正确做法是用子进程隔离串口操作，主进程仅通过信号调度并异步处理数据。
Workerman 本身不内置 Modbus、DL/T645、CJT188 等工业协议解析能力，也不能直接轮询串口或 485 设备；它只负责高性能的网络通信和定时调度。真正实现变电站/水质监测站数据采集，必须靠「协议适配层 + 定时器驱动 + 外部设备通信」三者协同——而最容易出问题的，恰恰是定时器与串口资源的并发冲突和超时兜底逻辑。
为什么不能直接用 Timer::add 轮询串口设备
Workerman 的 Timer::add 回调运行在 Worker 进程内，但 PHP 默认的串口操作（如 fopen('/dev/ttyS0', 'r+') ）是阻塞式 I/O。一旦某次读取因设备无响应、线缆松动或波特率错配卡住超过几秒，整个 Worker 进程就会被拖住，后续所有定时任务、WebSocket 消息、HTTP 请求全部延迟甚至堆积。
常见错误现象包括：
-
connections数持续上涨，total_request停滞，status显示多个进程处于busy - 轮询日志里出现大量重复的“等待响应超时”，但没触发关闭重连
- 串口设备偶尔能采到数据，多数时候返回空或乱码，且无法复位
正确做法：用子进程隔离串口 I/O，主进程只管调度
核心思路是把高风险的串口读写交给独立子进程（pcntl_fork），主 Worker 进程通过管道或信号与其通信，避免阻塞事件循环。Workerman 官方虽不推荐频繁 fork，但在采集类场景中这是最稳妥的方案。
实操要点：
- 在
onWorkerStart中启动一个子进程，专用于轮询某台水质监测仪（例如挂载在/dev/ttyUSB0，协议 CJT188） - 子进程内使用
stream_set_timeout($fd, 1, 500000)设置 1.5 秒级超时，失败后立即 close + reopen 串口 - 主进程用
Timer::add(30, function() { posix_kill($pid, SIGUSR1); })每 30 秒发一次信号，触发子进程发起一次完整采集流程 - 子进程采集成功后，将 JSON 数据写入共享内存或 Redis，主进程异步读取并入库（避免
mysqli_query阻塞）
如果必须走 TCP/RTU 网关，注意心跳与超时的嵌套关系
很多变电站现场已部署了支持 Modbus TCP 的智能网关（如物通博联 WG585），这时 Workerman 可以安全地发起 socket 连接。但要注意：Timer::add 的间隔不能简单设为“采集周期”，必须预留协议握手、重试、断连恢复的时间余量。
例如：要求每 60 秒采一次电表电压电流，实际应配置：
- 定时器间隔设为
65，而非60—— 预留 5 秒给连接建立和异常处理 - socket 连接必须显式设置
stream_set_timeout($client, 3, 0)，否则默认阻塞无上限 - 每次采集前先
ping网关 IP，失败则跳过本次，避免堆积无效连接 - MySQL 写入务必用异步方式（如
Workerman\MySQL\Connection的非阻塞 query），或投递到消息队列
容易被忽略的关键点：串口设备没有“连接”概念，只有“就绪”状态
开发者常误以为串口像 TCP 一样可以“保持长连接”，实际上每次读写都是独立的物理操作。即使你用 fopen 打开后一直不 fclose，设备端断电再上电，PHP 进程也不会感知，后续 fread 会一直返回 false 或阻塞。真正的健壮性来自两层检测：
- 每次采集前用
is_readable($fd)+stream_get_meta_data($fd)['timed_out']判断通道是否可用 - 连续 3 次采集失败后，强制
fclose+fopen重置串口句柄，而不是依赖定时器自动重试
这比任何 fancy 的重连策略都管用——因为工业现场的干扰，往往不是软件能预测的。
