90%是因为客户端协议不匹配或服务端未监听外部ip；tcp的onmessage只收裸字节流，不解析http/json/换行符，需确保监听0.0.0.0:端口、客户端发裸tcp、业务层自行处理粘包与分包。
Workerman TCP 的 onMessage 收不到数据，90% 是因为客户端发的不是裸字节流，或者服务端根本没收到包——它不解析 HTTP、不识别 JSON 封装、不等待换行符，只原样吐出 TCP 层传来的二进制数据。
监听地址必须是 0.0.0.0:端口，不能是 127.0.0.1:端口
Linux 内核对 127.0.0.1 有严格回环限制：外部设备（包括同局域网手机、ESP32、测试脚本）发的 SYN 包直接被丢弃，Workerman 连三次握手都看不到，onMessage 当然不会触发。
- 改完代码后必须完整重启：
php start.php stop && php start.php start，reload不生效 - 验证是否生效：
ss -tuln | grep :你的端口，输出中必须含*:你的端口或0.0.0.0:你的端口 - 如果看到
127.0.0.1:你的端口，说明配置没加载或被其他 Worker 覆盖
onMessage 的 $data 就是原始字节流，没有自动解析
TCP Worker 不做任何协议解析：没有 $_POST，没有 $request->post()，没有 URL 解码，也没有包边界识别。你收到什么，$data 就是什么。
- 客户端用
curl -X POST http://...发请求 → TCP Worker 收到一长串含 HTTP 头的乱码，onMessage确实触发了，但内容无法直读 - 客户端用
telnet 服务器IP 端口连上后敲hello\n→$data就是字符串"hello\n"（含换行） - 硬件模块（如 Modbus 设备、短信猫）发固定长度二进制帧 →
$data就是那几个字节，需按协议手册手动 unpack - 想按行处理？得自己
explode("\n", $data)或用stream_socket_enable_crypto配合缓冲逻辑
客户端协议类型必须和 Worker 实例化协议完全一致
Workerman 对协议是“零容忍”匹配：启的是 tcp://，客户端就必须走裸 TCP；启的是 http://，客户端就得发合法 HTTP 请求。混用会导致连接秒断、onMessage 根本不调用。
- ESP32 默认用
client.print("xxx")发裸 TCP → 必须配new Worker("tcp://0.0.0.0:2345") - 前端用
WebSocket连接 → 必须启websocket://协议，并实现握手逻辑，否则onConnect后立刻onClose - 用
nc -u测试 UDP → TCP Worker 完全无视，得换udp://实例 - 不确定客户端发什么？先用
tcpdump -i any port 2345 -w debug.pcap抓包看原始 payload
真正容易被忽略的点是：TCP 数据到达时机不可控，$data 可能是半包、粘包、多包合并。Workerman 不帮你拆包，也不缓存，onMessage 每次回调只对应一次 recv() 返回的内容。业务层必须自己处理分包逻辑，否则 JSON 解析失败、XML 截断、定长帧错位都会悄无声息地发生。
