Boost.Asio需搭配Beast或WebSocket++实现WebSocket，单io_context线程因回调堆积和锁竞争难以支撑500+连接；须避免耗时操作、正确管理buffer生命周期、启用TCP_NODELAY并调优内核参数。
Boost.Asio 本身不直接提供 WebSocket 协议实现，必须搭配 Beast 或 WebSocket++ 才能跑 WebSocket 服务。单纯用 boost::asio::ip::tcp::socket 写 WebSocket，会卡死在握手阶段或解析帧时崩溃——协议细节（如 Sec-WebSocket-Key 计算、mask 处理、frame opcode 判定）全得自己手撸，没人这么干。
为什么 io_context.run() 单线程撑不过 500 连接
单个 io_context 实例调用 run() 是阻塞式事件循环，所有回调都在同一线程执行。当连接数上升，回调堆积、锁竞争加剧（比如共享的连接容器）、CPU 成为瓶颈，延迟陡增。实测中，哪怕只是做 echo，1000 连接下平均响应时间就可能从 0.2ms 涨到 8ms+。
- 不要在回调里做耗时操作（如 JSON 解析、DB 查询），必须 offload 到线程池
- 避免在
io_context线程中使用std::mutex保护大范围数据结构；改用boost::lockfree::queue或分片锁 - 多线程启动方式要带
work：否则run()可能立刻返回 ——boost::asio::executor_work_guard<:asio::io_context::executor_type> work{io_context.get_executor()};
boost::beast::websocket::stream 的内存生命周期陷阱
Beast 的 stream 对象本身不持有 socket 缓冲区，但读写操作依赖外部 buffer（如 boost::beast::flat_buffer）。如果 buffer 是栈变量，而回调是异步触发的，就会出现 use-after-free。
- 必须把
flat_buffer和stream一起包进std::shared_ptr，传给异步操作的 lambda 捕获列表 - 不要复用同一个
flat_buffer给多个并发读操作；每个连接至少配一个独占 buffer - 关闭连接前，先调
ws.async_close()，再等 close 完成回调，最后才销毁对象；直接delete或离开作用域会触发未定义行为
Linux 下 epoll + TCP_NODELAY 是刚需，不是可选项
Boost.Asio 在 Linux 默认用 epoll，但默认不启用 TCP_NODELAY。小消息（比如心跳 ping/pong 或聊天短文本）会被 Nagle 算法攒包，导致 200ms 级别延迟抖动，实时性彻底崩坏。
- 在
accept后立即设置：socket.set_option(boost::asio::ip::tcp::no_delay{true}); - 检查是否生效：
getsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &flag, &len)返回值应为 1 - epoll 性能依赖内核参数，上线前务必调大：
net.core.somaxconn=65535、fs.file-max=1000000
真正难的不是写出能跑通的 WebSocket 服务，而是让每万连接下的 P99 延迟稳定在 1ms 内——这要求你对 io_context 调度粒度、buffer 分配路径、TCP 栈参数、甚至 CPU cache line 对齐都有控制力。Beast 提供了能力，但不会替你做这些决定。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
