websocketpp是当前最现实的C++ WebSocket客户端方案：无依赖、仅需Boost.Asio、支持C++11+且持续维护；需正确配置心跳、TCP keepalive、指数退避重连，并用异步send与线程安全队列处理消息。
为什么 websocketpp 是最现实的选择
直接说结论：C++ 标准库不提供 WebSocket 支持，websocketpp 是当前最成熟、无依赖（仅需 Boost.Asio）、支持 C++11+ 且仍在维护的客户端方案。别碰那些只有一两个 commit 的“轻量库”，它们连 401 Unauthorized 响应后重连都处理不好。
它本质是基于 Boost.Asio 的头文件库，编译时无需链接动态库，但必须确保 BOOST_ASIO_STANDALONE 或完整 Boost 已就位。常见错误是只装了 libboost-system-dev 却漏掉 libboost-thread-dev，导致链接时报 undefined reference to `boost::thread::joinable()'。
如何用 websocketpp::client 建立稳定长连接
关键不是“连上”，而是“连住”——网络抖动、服务端主动断开、DNS 变更都得扛住。默认配置下，websocketpp 不会自动重连，也不发 ping/pong。
- 启用心跳：调用
set_timer_handler+set_pong_handler，并在定时器里手动发ping（用send发空消息并设websocketpp::frame::opcode::ping） - 关闭超时保护：
set_connection_timeout(0)禁用连接阶段超时（否则 DNS 解析慢时直接失败） - 设置底层 TCP keepalive：通过
set_socket_init_handler获取boost::asio::ip::tcp::socket，调用socket.set_option(boost::asio::ip::tcp::socket::keep_alive(true)) - 连接失败后不要立即重试，用指数退避（如 1s → 2s → 4s），避免雪崩式重连请求
send() 同步 vs 异步：为什么你该用 send 的异步重载
全双工意味着收发互不阻塞。如果用同步 send（如 send("data", websocketpp::frame::opcode::text)），一旦网络卡住或缓冲区满，整个线程就卡死——这和“长连接”的初衷背道而驰。
立即学习“C++免费学习笔记（深入）”；
必须用异步版本：send(hdl, "data", websocketpp::frame::opcode::text, [this](websocketpp::lib::error_code ec) { if (ec) { /* 处理发送失败 */ } })。注意两点：
-
hdl（handle）必须在连接成功后的open_handler中保存，不能用全局变量传；它生命周期只在本次连接内有效 - 回调里的
ec不是连接错误，而是本次帧发送是否进入 Asio 输出队列。真正失败（如对端已断开）会在后续的fail_handler或close_handler中通知 - 大量小消息要合并发送？别自己拼包——
websocketpp内部已做 Nagle 合并，强行攒包反而增加延迟
收到消息后怎么安全地交还给业务线程
websocketpp 的消息回调（message_handler）运行在 Asio 的 IO 线程中，如果你在里面直接操作 GUI、数据库或共享容器，大概率触发竞态或崩溃。
标准做法是用线程安全队列中转：
- 用
std::queue+std::mutex+std::condition_variable实现一个简单生产者-消费者队列 - 在
message_handler里 push 消息（注意深拷贝msg->get_payload()，因为 msg 对象马上会被销毁） - 另起一个业务线程，wait 条件变量并 pop 处理——这样所有业务逻辑都在可控线程里执行
- 别用
std::async或std::thread在回调里临时起线程，容易创建过多线程拖垮系统
最易忽略的一点：message_handler 被调用时，连接可能已在另一线程中被 close() 或 terminate()。务必在 handler 开头检查 con->get_state() == websocketpp::session::state::open，否则 get_payload() 可能访问已释放内存。
