websocket帧类型需手动解析帧头opcode：0x1为text、0x2为binary、0x8为close、0x9为ping、0xA为pong；php无内置客户端，须用unpack取前两字节并$second & 0x0F提取opcode。
WebSocket 帧类型怎么从 PHP 连接里识别
PHP 本身没有内置 WebSocket 客户端，所以你用的大概率是 ext-websocket、ratchet/pawl、react/socket 或手写 socket + 协议解析。帧类型（如 text、binary、ping、pong、close）不靠 php 函数自动暴露，得自己从原始帧头里解出来。
关键点：WebSocket 帧结构固定，前 2 字节就含 FIN、RSV、opcode，其中 opcode 决定帧类型：
-
0x1→ text frame -
0x2→ binary frame -
0x8→ close frame -
0x9→ ping -
0xA→ pong
如果你用的是 react/socket 或原生 fsockopen + fread，读到数据后必须先解析帧头。例如，用 unpack('Cfirst/Csecond', $raw) 拿前两字节，再对 $second & 0x0F 取低 4 位得 opcode。
用 Ratchet/Pawl 怎么拿到原始帧或 opcode
ratchet/pawl 是高层封装，它默认把 text/binary 帧转成字符串/资源，直接丢掉 opcode 信息。想区分帧类型，不能只监听 onMessage，得换到更底层：
立即学习“PHP免费学习笔记（深入）”；
- 改用
PawlClient的on('data', ...)事件，接收原始二进制流 - 手动调用
WebSocketFrame::fromString($data)（需textalk/websocket包）还原帧对象 - 或者继承
PawlClient，重写handleData，在调用父类前先解析$data[0]和$data[1]
注意：onMessage 回调里的 $message 已经是解包后的 payload，opcode 丢了——这是最常踩的坑。
手写 socket 解析 WebSocket 帧头的实际步骤
从 fread($socket, 2) 开始，逐字节解析帧头，不是一步到位的事。真实步骤如下：
- 读前 2 字节：
$header = fread($socket, 2)，用unpack('Cfirst/Csecond', $header)得到数值 - 提取
opcode = $second & 0x0F；判断是否分片（$first & 0x80非零表示 FIN=1） - 看
$second & 0x80是否为 1，决定是否有 mask key（客户端发帧必有 mask，服务端回帧不能有） - 读 payload length：若
$second & 0x7F是 126，再读 2 字节；是 127，再读 8 字节；否则就是真实长度 - 如有 mask key（4 字节），读出来，再读 payload，最后用 mask 解密
别跳过 mask 解密——客户端发来的所有帧都带 mask，不处理会得到乱码，且 opcode 判断可能因错位而失败。
为什么 var_dump() 看不到帧类型，但抓包能看到
因为大多数 PHP WebSocket 库在收到数据后立刻解帧、去 mask、拼 payload，然后只把干净内容抛给上层回调。wireshark 或 tcpdump 抓的是裸 TCP 流，你看到的是原始帧头，自然包含 opcode 字段。
验证方法：在 fread 后立刻 bin2hex($raw) 打印前 16 字节，对照 RFC 6455 的帧格式查第一个字节的 bit 分布。比如 81 05 68 65 6c 6c 6f 中，81 的二进制是 10000001，FIN=1，opcode=1 → text frame；05 是 masked payload len=5。
真正难的不是解析，而是保持状态：分片帧（FIN=0）、连续多个 0x0 opcode 的 continuation frame，需要缓存上下文。这点几乎所有轻量库都默认忽略，得自己补。