Workerman 适合作为政务自助机远程协助的通信底座，因其轻量、稳定、协议可控，但需自行实现屏幕共享、鼠标控制等业务逻辑，并配合桌面采集工具与等保三级安全加固措施。
直接上结论：Workerman 适合做政务自助机远程协助的通信底座，但不能单独完成整套系统——它只管「连接、转发、保活」，业务逻辑（如屏幕共享、鼠标控制、文件传输）必须自己实现，且需配合桌面采集工具和安全加固措施。
为什么选 Workerman 而不是 WebSocket Server 或 Swoole？
政务自助机通常部署在内网边缘节点，对资源占用敏感、要求长期稳定运行，且多数不支持安装额外扩展。Workerman 的优势很具体：
-
workerman/workerman仅依赖 PHP 原生 socket，无需ext-swoole或ext-event，CentOS 7/8 + PHP 7.4+ 即可开箱即用 - 进程模型清晰：每个
Worker实例独立，崩溃不影响其他连接，适合自助机这种“单点故障即服务中断”的场景 - 心跳与连接超时可控：
$connection->send()失败后能立刻触发onClose，比 WebSocket 协议层的心跳更贴近 TCP 真实状态，便于快速感知终端离线 - 不内置 HTTP/WebSocket 协议解析，反而成了优势——政务系统常需自定义二进制协议头（如加签名、加密字段），Workerman 允许你直接操作
$data原始字节流
远程协助必须解决的三个核心数据通道
政务自助机远程协助不是简单聊天，至少要打通三路数据，每路都要在 onMessage 中区分处理：
-
指令通道：用于下发控制命令，如
"cmd:screen_capture"、"cmd:mouse_move,x=120,y=85"。建议用固定前缀 + JSON body，避免粘包干扰 -
画面通道：屏幕帧不能走同一连接实时推送（会阻塞指令）。必须另起一个长连接或复用连接但加类型标识（如首字节为
0x01表示视频帧），且需客户端主动请求关键帧（I帧），否则 UDP 丢包时无法恢复 -
文件通道：大文件（如打印回执 PDF）不能直接
$connection->send($big_file)，会卡死事件循环。应拆成 chunk，每 chunk 加序号和校验（如 CRC32），由客户端拼接并校验完整性
示例片段（服务端识别指令）：
$tcp_worker->onMessage = function ($connection, $data) {
if (strlen($data) id);
}
break;
case 0x01: // 视频帧
handle_video_frame($connection->id, $payload);
break;
case 0x02: // 文件块
save_file_chunk($connection->id, $payload);
break;
}
};
政务场景下最容易被忽略的安全硬约束
不是加个 HTTPS 就算安全——自助机直连政务内网，远程协助通道必须满足等保 2.0 三级要求：
- 所有连接必须双向证书认证：
ssl://0.0.0.0:8443启动时指定context，且服务端验证客户端证书的subjectAltName是否匹配预置白名单（如cn=zhengwu-kt-001） - 指令执行前强制鉴权：不能只靠连接时的 token，每次
cmd:mouse_click都要查 Redis 缓存中的会话有效期（auth:session:{conn_id}），超时立即拒绝 - 屏幕采集必须本地授权：Workerman 进程本身无权调用
ffmpeg -f gdigrab，需由独立的守护进程（如 systemd service）监听本地 UnixSocket，接收 Workerman 转发的 capture 请求，再返回 PNG 数据流 - 禁止任何动态代码执行：严禁在
onMessage里用eval()、create_function()或system()调用 shell 命令，哪怕注释里写着“仅供调试”也不行
真正难的不是写通连接，而是让每一帧画面、每一次点击、每一份回执，在通过网络时都经得起审计——协议字段要留审计标记位，连接断开要留完整日志（含 IP、证书 CN、操作时间戳），这些细节不提前设计，上线后补成本极高。
