boost.beast同步websocket连接需先用tcp::resolver解析域名，再调用stream.next_layer().connect()和tls握手，最后websocket::stream::handshake()；发送二进制帧前必须设stream.binary(true)；接收需循环read处理fragment帧。
用 Boost.Beast 同步发 WebSocket 消息，别卡在 stream.next_layer().connect()
Boost.Beast 是目前 C++ 里最靠谱的 WebSocket 客户端方案，但新手常卡在连接建立阶段——不是连不上，而是没等 DNS 解析完就超时，或忽略 TLS 层初始化。同步模式下，stream.next_layer().connect() 必须在调用 websocket::stream::handshake() 前完成，且不能跳过 resolver 解析步骤。
常见错误现象：boost::system::error_code: 110 (Connection timed out) 或直接抛 std::runtime_error: resolve: Host not found (authoritative)。
- 先用
tcp::resolver解析域名，不要手拼 IP + 端口硬编码（尤其 wss 场景下 DNS 和证书绑定强相关） - wss 连接必须显式调用
stream.next_layer().handshake(ssl::stream_base::client)，且要在websocket::stream::handshake()之前 - 同步模式下，所有操作（解析、TCP 连接、TLS 握手、WebSocket 协议握手）都是阻塞的，超时需靠
boost::asio::steady_timer手动控制，Beast 本身不提供 connect_timeout 参数 - 示例关键片段：
tcp::resolver resolver{ioc}; auto const results = resolver.resolve("echo.websocket.org", "443"); stream.next_layer().connect(results); stream.next_layer().handshake(ssl::stream_base::client); stream.handshake("echo.websocket.org", "/");
websocketpp 编译失败：找不到 websocketpp/config/asio_no_tls.hpp
这个头文件缺失，90% 是因为 websocketpp 的子模块没拉全，或者你用了较新版本（0.8.x+）但项目仍按旧文档引用非 TLS 配置——新版默认要求 TLS 支持，asio_no_tls.hpp 已被移除。
使用场景：想快速跑通纯 ws（非 wss）测试，又不想配 OpenSSL。
立即学习“C++免费学习笔记（深入）”；
- 降级到 websocketpp 0.7.0 是最快解法，该版本仍保留
asio_no_tls.hpp - 若坚持用 0.8.x+，必须启用 TLS：编译时加
-DWEBSOCKETPP_USE_ASIO_STANDALONE并链接libssl和libcrypto，配置头改为websocketpp/config/asio_client.hpp - 别手动复制旧版头文件到新项目——路径和内部模板特化已变，大概率触发
static_assert失败或链接错乱 - 错误信息典型特征：
fatal error: websocketpp/config/asio_no_tls.hpp: No such file or directory，同时make报undefined reference to 'SSL_CTX_new'
Boost.Beast 发送二进制帧时，stream.write() 返回成功但服务端收不到
问题不在发送函数本身，而在帧类型标识。Beast 默认把 const_buffer 当文本帧（opcode 1），哪怕你传的是 uint8_t* 数组。服务端严格校验 opcode，遇到文本帧里有非法 UTF-8 字节会静默丢弃。
性能影响：设错 opcode 不影响吞吐，但会导致协议层不可靠；兼容性上，所有主流服务端（ws, socket.io, nginx-ws-proxy）都按 RFC 6455 校验 opcode。
- 发二进制数据前，必须调用
stream.binary(true)，且该设置是 per-message 的，每次发前都要设（不是连接级开关） - 文本帧用
stream.text(true)，但注意：Beast 不做 UTF-8 校验，你传非法序列它也照发，服务端可能拒收 - 别依赖
stream.got_binary()反推状态——它是读取时用的，对发送无意义 - 简短验证方式：
stream.binary(true); stream.write(net::buffer(std::vector<uint8_t>{0x01, 0xff, 0x80}));
Beast 客户端收消息时，stream.read() 阻塞不返回，但服务端明明发了
根本原因通常是缓冲区太小，或没处理 fragmented frame。WebSocket 协议允许单条消息被拆成多个 continuation frame，而 Beast 的 stream.read() 默认只收一帧（frame），不是一条完整 message。
容易踩的坑：以为 stream.read() 和 TCP recv() 行为一致，其实它受 WebSocket 帧边界约束。
- 要收整条逻辑消息，必须循环调用
stream.read()直到frame_info.fin == true，并自己拼接 payload - 更稳妥的做法是用
stream.async_read()配合自定义 buffer（如beast::flat_buffer），并在回调里检查boost::beast::websocket::frame_type - 缓冲区大小建议 ≥ 8192 字节，小于 1024 容易触发频繁 reallocation，影响小包吞吐
- 调试技巧：开启 Beast 日志（
#define BOOST_BEAST_SEVERITY_LEVEL debug），看是否打印fragment或continuation
