Workerman不提供滑点计算逻辑，仅负责高效转发与长连接维持；滑点监控需业务层对接MT4/MT5桥接器、FIX网关或行情API，获取带exec_id、fill_price、timestamp的成交回执，再比对订单触发价并按货币对小数位校准计算。
Workerman 本身不提供滑点计算逻辑，也不直接对接外汇行情源；它只负责高效转发、广播和维持长连接。真正的滑点监控必须由业务层完成——你得自己从 MT4/MT5 桥接器、FIX 网关或第三方行情 API（如 OANDA、IG、Dukascopy）拿到原始报价与成交记录，再比对时间戳和价格差。否则，光靠 onMessage 收到的“客户端下单请求”根本无法算滑点。
滑点监控必须依赖真实成交数据，不是 WebSocket 消息
常见错误是把用户前端提交的订单价格（比如 $data['price']）和服务器收到时的最新行情价做对比，这叫“延迟感知”，不是滑点。滑点定义是：实际成交价与用户下单时意图成交价之间的差值（单位：点数），且必须基于经纪商返回的 execution report 或 trade record。
- 滑点 = |实际成交价 − 订单触发价| × 点值（pip value），需按货币对小数位校准（EUR/USD 是 5 位，USD/JPY 是 3 位）
- 必须拿到带
exec_id、order_id、fill_price、timestamp的成交回执，才能绑定到原始订单 -
onMessage只能收下单指令，不能替代 FIX/MT 接口或交易网关
用 Workerman 实现低延迟滑点采集的关键配置
Workerman 不是消息队列，但可以作为轻量级中继节点，把成交事件快速推给监控前端。重点不在“怎么写 onMessage”，而在怎么避免进程阻塞和时钟漂移：
- 所有行情与成交数据必须走
Worker::sendToAll()或$connection->send()，禁用同步 cURL 或 file_get_contents - 启用
$ws_worker->reloadable = false;，防止 reload 时丢掉未处理完的成交包 - 设置
$ws_worker->reusePort = true;（Linux ≥ 3.9），提升多核 CPU 下的连接分发效率 - 不要在
onMessage里做数据库写入，改用Worker::safeExec()或投递到 Redis 队列异步落库
预警逻辑必须脱离 Worker 进程独立运行
滑点超阈值（比如 EUR/USD > 1.5 pip）的判断不能卡在 onMessage 回调里。否则高并发下单时，预警会堆积、延迟甚至漏报：
- 推荐用
LibTimer::add()启动一个每 100ms 扫描一次内存队列的定时器，检查最近 5 秒内的成交记录 - 滑点统计建议用环形缓冲区（如 SplDoublyLinkedList + count 控制长度），而非全量数组，避免内存暴涨
- 预警推送走单独的
Worker实例（比如监听text://0.0.0.0:2347），和主 WebSocket 服务解耦 - 前端连接监控页时，应主动拉取最近 10 条滑点事件，而不是等首次
onOpen后才开始接收
onMessage 就搞定滑点监控——先理清你的成交数据从哪来、格式是否带纳秒级时间戳、有没有重复推送，这些才是关键。 
