workerman通过tcp协议接入银行柜台评价器设备，设备需主动连接指定端口并发送认证包完成绑定，评价数据经gatewayworker转发至后台api处理，后台可反向下发指令控制设备。
Workerman 本身不直接处理银行柜台评价器的硬件交互，它只负责 TCP/WebSocket 长连接通信和消息路由。真正的“评价器”设备（如带按键/LED屏的物理终端）需通过自定义 TCP 协议接入 Workerman，再由 BusinessWorker 或 GatewayWorker 转发到 ThinkPHP/Laravel 后台管理系统——关键在于协议对齐、连接绑定与状态同步。
评价器设备如何用 TCP 连接到 Workerman
银行柜台评价器通常是嵌入式 Linux 设备或 Windows 工控机，运行一个轻量客户端，主动连接 Workerman 的 TCP 端口（非 WebSocket）。不能用 websocket://，必须用 tcp:// 协议初始化 Worker。
-
$worker = new Worker('tcp://0.0.0.0:8282');—— 不要写成ws://或wss://，否则设备连不上 - 设备上线时需发送固定格式的认证包，例如 JSON：
{"type":"auth","counter_id":"T001","token":"abc123"}，Workerman 在onMessage中解析并存入$worker->counterConnections['T001'] = $connection; - 务必在
onConnect中设置超时：$connection->timeout = 30; 防止断网后连接滞留 - 设备断线重连时，
onClose要清理$worker->counterConnections对应键，否则后续消息会发丢
评价数据怎么推给后台管理系统
Workerman 不处理数据库或业务逻辑，只做“管道”。评价事件（如“满意”“一般”“差评”）到达后，必须转发给 PHP 后台（ThinkPHP/Laravel）做落库、通知、统计。
- 推荐用 GatewayWorker 架构：评价器 →
Gateway（TCP 接入）→BusinessWorker（调用 HTTP API）→ 后台系统/api/v1/counter/feedback - 不要在
BusinessWorker里直接查 MySQL：PHP-FPM 和 Workerman 共享数据库连接会导致连接数爆满；统一走 REST 或 RPC - HTTP 调用建议加简单重试（最多 2 次）+ 异步队列兜底，避免因后台短暂不可用丢失评价
- 转发时附带原始设备上下文：
{"counter_id":"T001","score":5,"timestamp":1747907820,"session_id":"sess_abc"}，后台靠counter_id关联柜台信息
后台管理系统怎么反向控制评价器
比如营业结束时清空屏幕、切换欢迎语、点亮“暂停服务”灯——这些指令必须从后台发起，经 Workerman 下发到指定设备。
- 后台调用
GatewayClient发送消息：Gateway::sendToUid('T001', '{"cmd":"show","text":"请对本次服务打分"}'); -
uid必须与柜台编号严格一致（大小写、前导零都不能错），否则指令发错设备 - 设备端需实现心跳保活（每 15 秒发一次
{"type":"ping"}），Workerman 用onWebSocketConnect或自定义onMessage处理，超时未心跳则自动踢出连接 - 指令失败不报错：设备可能离线，
sendToUid返回false时，后台应记录日志并可选触发短信告警
最易被忽略的是设备唯一性绑定与状态一致性。柜台编号在评价器固件、Workerman 内存映射、后台数据库三处必须完全一致；任何一处脱节，就会出现“A 柜台评价落到 B 柜台报表”这种生产事故。上线前务必用真实设备跑通全流程，而不是只测 WebSocket 浏览器模拟器。
