C++无标准WebSocket库，必须用第三方库；推荐Boost.Beast（类型安全）、libwebsockets（稳定）或uWebSockets（轻量）；需注意握手校验、读写串行、字节序与内存布局等关键细节。
WebSocket 在 C++ 里没有标准库支持
别找 std::websocket——C++ 标准库里压根没这玩意。所有所谓“C++ WebSocket 实现”都依赖第三方库，选错库或用错接口，直接卡在握手失败、收不到消息、内存泄漏上。
主流靠谱选项就三个：libwebsockets（C 风格，稳定但 API 略重）、Boost.Beast（C++17+，类型安全强，推荐新手）、uWebSockets（极致轻量，但 C++ 封装弱，容易裸指针误用）。别碰那些年更 5 年以上、issue 堆成山的“轻量库”，它们连 Sec-WebSocket-Accept 计算都可能出错。
Boost.Beast 实现双向通信最稳的写法
用 boost::beast::websocket::stream 时，必须同步处理读写——它不自动管理读写并发，不是“开个线程丢进去就完事”。常见错误是：一边 async_read 没结束，另一边又发 async_write，触发 operation_aborted 或静默丢包。
- 读写必须串行协调：用
boost::asio::strand包一层io_context，避免竞态 - 发送前检查连接状态：
ws.is_open()，别只靠异常捕获 - 文本帧必须用
boost::beast::websocket::text显式标记，否则对方可能当二进制处理 - 接收缓冲区别用栈变量：传给
async_read的boost::beast::flat_buffer必须生命周期长于异步操作
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
ws.async_read(buffer, beast::bind_front_handler(&session::on_read, shared_from_this()));
注意 on_read 里处理完数据后，要立刻再调一次 async_read，否则连接就“哑了”。
libwebsockets 客户端连不上服务端的典型原因
90% 的“连接成功但没响应”问题出在协议协商阶段，不是网络层。libwebsockets 默认启用严格校验，而很多 Node.js/Python 的 WebSocket 库对 header 处理宽松，导致握手被拒。
- 服务端返回的
Sec-WebSocket-Accept值必须和客户端计算的一致，差一个空格就失败——用lws_get_context查日志，开LWS_LOG_LEVEL_PROTOCOL级别 - 客户端必须显式设置子协议：
protocol = "json"这类，和服务端对齐，否则lws_callback_on_writable可能永不触发 - 别手动拼 HTTP Upgrade 请求：用
lws_client_connect_via_info，别碰lws_http_client_read - SSL 握手失败时，
lws_get_socket_fd返回 -1，但错误码藏在lws_get_context的日志里，不看日志根本不知道是证书过期还是 SNI 没设
二进制消息传输时字节序和内存布局最容易翻车
WebSocket 协议本身不管数据内容，但 C++ 里 uint32_t 直接塞进 write，对方 Java/JS 拿到就是乱码——因为没约定字节序，也没处理结构体 padding。
- 固定字段一律用网络字节序：
htonl()/htons()转，别信“小端机器发小端就对” - 结构体不能直接
reinterpret_cast<char>(&s)</char>发：加#pragma pack(1)或用std::memcpy按字段拷贝 - 接收方必须校验帧长度：WebSocket 的
payload_len字段可能被篡改，别无条件resize接收 buffer - 如果用 Protobuf，确保双方 schema 版本一致，且
ParseFromArray前检查返回值，别跳过if (!msg.ParseFromArray(...))
真正麻烦的从来不是连上，而是连上之后，一发二进制数据，对方解出来字段全偏移 1 字节——这种问题查起来得翻协议 RFC 和内存 dump，不是加个 log 就能定位的。
