c++ websocket客户端无标准库支持，主流选型为libwebsockets（轻量、嵌入友好）和boost.beast（现代异步、支持co_await）；需规避已停更的websocketpp。
WebSocket C++ 客户端该用哪个库
没有标准库，std:: 里压根没 websocket。别被“C++ WebSocket 教程”标题骗了——99% 的所谓“教程”其实是在包装第三方库，不是语言原生能力。
主流选型就两个：libwebsockets（C 风格，轻量、嵌入友好）和 Boost.Beast（C++11+，类型安全、异步模型清晰）。前者编译快、内存可控；后者写法更现代，但依赖 Boost，链接体积大、编译慢。
-
libwebsockets适合嵌入式、IoT 或对启动时间敏感的场景，回调驱动，容易写出阻塞逻辑 -
Boost.Beast更适合服务端或桌面应用，支持asio::awaitable，能用co_await写同步风格代码 - 别碰
WebSocketPP：已停止维护，C++11 支持不完整，TLS 配置坑多，make_shared相关崩溃在 GCC 12+ 上高频出现
Boost.Beast 连不上服务器？检查这三处
最常见现象是 handshake failed: websocket: bad status 或直接卡在 async_handshake 不返回。不是代码写错，而是握手阶段就被拦下了。
- HTTP 升级头必须显式设置：
req.set(http::field::upgrade, "websocket")，漏掉就当普通 HTTP 请求处理 - Sec-WebSocket-Key 必须由库自动生成（
beast::websocket::stream::handshake内部生成），手动生成或硬编码会导致 400 - 如果服务端用 Nginx 反代，确认它开了 WebSocket 支持：
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade缺一不可
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
ws.async_handshake(host, "/ws", [](error_code ec) {
if (ec == websocket::error::closed) return; // 正常关闭
if (ec) return fail(ec, "handshake"); // 其他错误要查上面三点
});
libwebsockets 启动后立刻断连？看日志级别和上下文销毁
典型表现：调用 lws_client_connect_via_info 返回非空指针，但几毫秒后触发 LWS_CALLBACK_CLIENT_CONNECTION_ERROR，且 lws_get_context 日志为空——说明上下文生命周期管理出问题。
-
libwebsockets是事件循环驱动，lws_context必须全程存活，不能在函数栈上创建或过早lws_context_destroy - 默认日志等级太低，看不到关键错误，启动前加
lws_set_log_level(LLL_ERR | LLL_WARN | LLL_NOTICE, nullptr) - SSL 初始化失败不会报错，只静默降级为 ws://，若服务端强制 wss:// 就会立即断连；确认
lws_context_creation_info.ssl_cert_filepath路径可读且格式为 PEM
消息收发时出现乱码或截断
不是编码问题，是 WebSocket 帧边界和缓冲区管理没对齐。C++ 库不自动拼包，text/binary 帧需自行处理分片逻辑。
-
Boost.Beast默认启用自动分片（ws.auto_fragment(true)），但接收端仍需按帧处理：每次read拿到的是完整帧，不是流式字节，别当成tcp::socket::read_some用 -
libwebsockets的LWS_CALLBACK_RECEIVE回调中，len是单帧长度，若服务端发了超长文本帧（>64KB），需检查info.max_http_header_pool是否足够，否则被截断 - 二进制消息别用
std::string存——std::string会把\0当结束符，改用std::vector<uint8_t></uint8_t>或boost::beast::flat_buffer
这事没法靠“试试看”绕过去，帧结构、掩码、控制帧（ping/pong）响应都得按 RFC 6455 对齐。越想省事跳过协议细节，后面 debug 越像在猜谜。
