优先选websocketpp或boost::beast：前者成熟稳定、文档全、社区活跃；后者是Boost官方组件，与boost::asio深度集成，适合已用Boost的项目；切勿手写RFC 6455协议解析。
直接用现成库比手写协议解析靠谱得多，除非你明确需要极致精简或已有网络栈无法替换。
选哪个C++ WebSocket库最省事
优先考虑 websocketpp 或 boost::beast。前者成熟稳定、文档全、社区活跃；后者是 Boost 官方组件，与 boost::asio 深度集成，适合已用 Boost 的项目。别碰自己手撕 RFC 6455 —— 握手校验、掩码处理、分片重组、ping/pong 响应这些细节出错率极高，且调试成本远超预期。
-
websocketpp依赖Boost.Asio，但提供asio_no_tls.hpp配置可绕过 OpenSSL（适合纯 WS 场景） -
boost::beast要求 C++14+，且需完整 Boost 安装，但类型安全更强、错误提示更准 - Simple-WebSocket-Server 虽轻量，但更新慢、TLS 配置容易卡在证书链验证上
- libwebsockets 是 C 库，C++ 封装层易出生命周期问题，尤其在多线程回调中
握手失败常见原因和验证方法
前端报 WebSocket connection to 'ws://...' failed，90% 出在握手阶段。不是代码逻辑错，而是 HTTP 头缺失或格式不对。
- 必须返回状态码
101 Switching Protocols，不能是200 OK或其他 -
Upgrade: websocket和Connection: Upgrade头缺一不可，大小写敏感 -
Sec-WebSocket-Accept必须由客户端发来的Sec-WebSocket-Key拼接固定字符串258EAFA5-E914-47DA-95CA-C5AB0DC85B11后做 SHA-1 + Base64，不能直接 echo key - 用
curl -i -N -H "Upgrade: websocket" -H "Connection: Upgrade" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" http://localhost:8080手动触发握手，看响应头是否合规
消息收发时的内存与线程陷阱
收到消息后立刻调用 send() 看似简单，但实际极易 crash 或丢消息 —— 因为 websocketpp 默认异步发送，底层缓冲区可能未就绪；boost::beast 则要求显式管理读写缓冲区生命周期。
立即学习“前端免费学习笔记（深入）”；
- 在
on_message回调里直接调用send()前，确认连接句柄connection_hdl仍有效（get_con_state() == open） - 避免在回调中做耗时操作（如 JSON 解析、数据库查询），否则阻塞整个 IO 线程池
- 若需广播，不要遍历
std::set<connection_hdl></connection_hdl>并逐个send()—— 改用send_to_all()（websocketpp）或批量写入（beast） - 二进制消息务必设
message_type::binary，否则前端onmessage收到的是乱码 ArrayBuffer
前端连不上本地 C++ 服务的典型配置漏项
开发时习惯用 localhost，但浏览器同源策略和 WebSocket 协议对 host 校验更严，稍有偏差就静默失败。
- C++ 服务监听地址不能只写
"127.0.0.1"，得用"0.0.0.0"或明确绑定"localhost"（部分库默认只绑 127.0.0.1） - 前端
new WebSocket("ws://localhost:8080")中的localhost必须与服务端 bind 的 hostname 完全一致 —— 若服务端 bind"127.0.0.1"，前端也得用"ws://127.0.0.1:8080" - Chrome 会拦截不安全的 ws 连接（当页面是 https 时），此时必须用
wss://并配好证书，或临时用chrome://flags/#unsafely-treat-insecure-origin-as-secure（仅测试） - 防火墙常默认拦截非标准端口，
sudo ufw status看下 8080 是否开放，或临时关掉：sudo ufw disable
真正麻烦的从来不是“怎么连上”，而是连接长期存活下的心跳维持、断线重连策略、消息顺序保证和异常连接清理 —— 这些没写进 hello world 示例，但上线第一天就会撞上。
