优先选 boost.beast，除非嵌入式受限或必须用 c 风格 api；它基于 boost.asio，c++11+ 原生异步、错误清晰、生态兼容好，而 libwebsockets 虽控制力强但需手动管理内存、事件循环和 ssl。
WebSocket 客户端用 libwebsockets 还是 Boost.Beast？
直接说结论：优先选 Boost.Beast，除非你嵌入式受限或必须用 C 风格 API。libwebsockets 是 C 库，封装层薄、控制力强，但要自己管内存、事件循环、SSL 初始化；Boost.Beast 基于 Boost.Asio，C++11+ 原生风格，异步写法自然，错误路径清晰，且和主流网络栈（如 std::shared_ptr、asio::ssl::stream）无缝衔接。
常见错误现象：libwebsockets 项目里忘记调 lws_context_destroy() 导致进程退出卡死；Boost.Beast 里没把 websocket::stream 和 tcp::socket 绑定在同一个 io_context，结果连接成功但收不到消息。
-
Boost.Beast要求所有异步操作生命周期由用户保证（比如buffer必须活过async_read回调） -
libwebsockets的lws_write()返回值不是字节数而是状态码，负数不等于失败，得查LWS_WRITE_NO_WSI等宏 - 若服务器启用了 permessage-deflate，
Boost.Beast默认不开压缩，需显式调用stream.set_option(websocket::stream_base::compression{true})
怎么发二进制帧而不被服务端当成文本？
WebSocket 协议靠帧头里的 opcode 区分文本（0x1）和二进制（0x2），C++ 客户端库不会自动猜——你传什么类型，它就设什么 opcode。
使用场景：传 Protobuf、JPEG、自定义结构体时，必须走二进制帧；如果误用 write(buffer) 发 raw bytes 却没指定类型，Boost.Beast 默认当文本处理，服务端解析会报 invalid utf8 或直接断连。
立即学习“C++免费学习笔记（深入）”；
-
Boost.Beast发二进制：用stream.binary(true)+stream.write(...)，或直接调stream.write(boost::beast::websocket::frame_type::binary, ...) -
libwebsockets发二进制：调lws_write(wsi, data, len, LWS_WRITE_BINARY)，别用LWS_WRITE_TEXT - 注意 buffer 生命周期：不要传栈变量地址给异步写，容易悬垂；
Boost.Beast推荐用boost::beast::flat_buffer或堆分配的std::vector<uint8_t></uint8_t>
心跳（ping/pong）不自动处理，连接就悄悄断了
大多数 WebSocket 服务器（如 Nginx、Spring WebFlux、FastAPI WebSocket）默认 60 秒没收到 ping 就关连接。C++ 客户端库不自动发 ping，也不自动回 pong——这事得你写逻辑。
性能影响：频繁 ping 增加小包开销；间隔太长又容易被中间设备（如 NAT、防火墙）断流。建议 45 秒发一次 ping，超时阈值设为 10 秒。
-
Boost.Beast：调stream.set_option(websocket::stream_base::timeout::suggested(beast::role_type::client))只设读超时，不解决 ping；得自己用net::steady_timer定期stream.ping() -
libwebsockets：注册回调监听LWS_CALLBACK_CLIENT_RECEIVE_PONG，并在主循环里调lws_callback_on_writable()触发 ping - 别在 ping 回调里直接发数据：可能破坏帧边界，导致服务端解析错乱
SSL/TLS 握手失败，错误信息是 unhandled exception: handshake: certificate verify failed
这不是证书问题，是客户端没配 CA 证书路径或禁用了验证。默认情况下，Boost.Beast（通过 boost::asio::ssl::context）和 libwebsockets 都要求验证服务端证书，而你本地没提供信任链。
兼容性影响：绕过验证（ctx.set_verify_mode(asio::ssl::verify_none)）能连通，但上线后会被中间人攻击；硬编码系统 CA 路径（如 /etc/ssl/certs/ca-certificates.crt）在 macOS 或 Windows 上失效。
-
Boost.Beast正确做法：用ctx.add_certificate_authority(...)加载 PEM 格式 CA bundle，推荐用 curl 官方 ca-bundle.crt -
libwebsockets：初始化 context 时传lws_context_creation_info.ssl_ca_filepath指向 CA 文件 - macOS 用户注意：
certifiPython 包的证书路径不通用，别抄；用 Homebrew 安装的 OpenSSL 的openssl.cafile位置也常变，最好随程序自带一份
双向通信真正的复杂点不在连接建立，而在连接存活期间的状态同步：比如 pong 回复延迟导致心跳超时、二进制帧被 TCP 分片后重组失败、SSL 重协商时异步读写交叉引发 crash。这些没法靠一个库开关解决，得结合日志、Wireshark 抓包、以及服务端 access log 对齐时间戳才能定位。
