WebSocket服务端必须校验UTF-8有效性、正确处理分片、严格解析掩码：Text帧需在解码和拼接后校验UTF-8；Binary分片须维护上下文并防超限；掩码解码须按RFC逐字节异或且类型安全；推荐环形缓冲区+std::string_view零拷贝交付。
Text帧必须校验UTF-8有效性，不能只看opcode==0x1
很多C++服务端一收到opcode == 0x1就直接当字符串处理，结果客户端发了个非法UTF-8序列（比如截断的中文、乱序字节），服务端std::string照单全收，后续日志炸、JSON解析崩、前端显示，但错误根本不在WebSocket层——它只是透传了坏数据。
真正该做的是：在交付上层前，用轻量UTF-8校验函数扫一遍unmaskedpayload。别调用std::codecvt_utf8这种重家伙，手写一个4分支判断就够了：检查首字节范围、后续字节是否都以0x80开头、总长度是否匹配。校验失败应立即关闭连接或丢弃该帧，而不是静默吞掉。
- 浏览器发中文时可能分片，
FIN==0的Text帧只是半截UTF-8字符，必须等FIN==1再校验 - 校验位置必须在掩码解码后、拼接分片后，不能在校验前就转
std::string - 若业务允许“容忍部分乱码”，至少记录
payload.length()和非法起始偏移，方便定位源头
Binary帧分片不等于“按需拆”，而是由发送方控制FIN与opcode组合
遇到opcode == 0x2且FIN == 0，不代表“这包太大要拆”，而只是发送方选择了分片策略。C++服务端常见错误是：收到第一个Binary帧就malloc一块大缓冲区，然后死等后续opcode == 0x0帧，结果客户端突然断连，缓冲区永远不释放。
正确做法是给每个连接维护一个分片上下文对象，含expected_opcode（首次分片的opcode）、total_size（可选，由首个帧的Payload Length字段推算）、received_size。每收到一帧，追加到std::vector<uint8_t></uint8_t>或预分配buffer中，同时检查是否超限（比如超过MAX_DEVICE_MESSAGE_SIZE）。
立即学习“C++免费学习笔记（深入）”；
- 连续帧
opcode == 0x0必须紧随非0 opcode之后，否则是协议违规，直接close(1002) - 分片中途收到
opcode == 0x8（Close）或opcode == 0x9（Ping），应先完成当前消息组装再响应，不能中断 - 避免用
std::string存Binary数据——它隐含null终止假设，二进制里随时可能出现\x00
服务端禁用掩码是硬性要求，但接收时仍要解析Mask位
RFC 6455白纸黑字：服务端收到Mask == 1必须处理掩码，收到Mask == 0必须拒绝。但不少C++实现把“服务端不发掩码”误解成“服务端不用管掩码”，导致读帧头时跳过Masking Key字段，后续所有payload解码全错位。
关键点在于：掩码解码是逐字节异或，必须严格按RFC定义的4字节Masking Key顺序，对payload从第0字节开始循环异或。别用std::transform配lambda偷懒——它不保证执行顺序，多线程下可能出错。
- 解码前先检查
masked标志位，为0则直接close(1002)，不许往下走 - Masking Key就在帧头末尾，长度固定4字节，不要依赖
payload_len去算偏移 - 异或操作必须用
uint8_t类型变量，避免char符号扩展导致异或结果错乱
分片合并性能瓶颈常在内存拷贝，不是解析逻辑
实测发现，当单条消息被切成20+帧时，90%耗时花在std::vector::insert或memcpy上，而非opcode判断或UTF-8校验。尤其在IoT场景，设备频繁上报小包，服务端每秒处理上千分片，堆分配+拷贝就是雪崩起点。
解决方案是预分配+零拷贝：为每个连接配置READ_BUFFER_SIZE（如8KB），用环形缓冲区管理未完成分片；新帧到来时，直接write_ptr写入，仅更新长度计数器；FIN帧到达后，用std::string_view或std::span（C++20）切出完整视图交付业务，避免任何内存复制。
- 环形缓冲区大小必须大于最大单消息预期值，否则分片写入会覆盖旧数据
- 交付视图后，要显式标记该分片段为“已消费”，否则下次读取可能重复交付
- 若用C++17，
std::string_view比const char*更安全——它带长度，不会因payload含\x00而提前截断
