因为boost::asio::ip::tcp::socket仅处理字节流，不解析HTTP协议，需手动实现请求边界识别、状态机及缓冲管理，易因粘包/半包导致阻塞或崩溃；而boost::beast封装了HTTP解析、序列化与缓冲，提供类型安全的http::request_parser和http::response_serializer，自动处理Content-Length、分块编码及prepare_payload()等细节。
为什么不能直接用 boost::asio::ip::tcp::socket 处理 HTTP 请求
因为 HTTP 是应用层协议，boost::asio::ip::tcp::socket 只管收发字节流，不解析请求行、头字段、分块编码或 Content-Length 边界。你得自己写状态机来判断一个完整请求是否收齐——稍有疏忽就会卡在半包/粘包上，比如收到 "GET / HTTP/1.1\r\nHost: l" 就停住，后续数据还在缓冲区里。
常见错误现象：read_some 返回后直接 parse，结果 std::string::find("\r\n\r\n") 找不到，程序阻塞或崩溃；或者把两个请求拼成一个字符串解析，触发越界访问。
- 必须维护 per-connection 的读缓冲区（如
std::vector<char></char>），累积数据直到检测到完整请求边界 - 要区分
Content-Length和Transfer-Encoding: chunked两种消息体结束方式 - HTTP/1.1 默认 keep-alive，不能处理完就 close socket，得检查
Connection: close头
如何用 boost::beast 替代手写解析逻辑
boost::beast 是 Boost.Asio 的 HTTP/WS 协议层封装，它把解析、序列化、缓冲管理全包了。你不需要自己切 \r\n，也不用算 chunk size —— 它提供 http::request_parser<:string_body></:string_body> 和 http::response_serializer<:string_body></:string_body> 这类类型安全的工具。
使用场景：快速启动一个返回静态文本或 JSON 的服务，比如健康检查接口 GET /health 或 mock API。
- 安装时确保 Boost 版本 ≥ 1.69（
beast自 1.70 起随 Boost 发布，无需单独编译） - 链接时仍只需
-lboost_system，beast是纯头文件库 - 避免用
http::dynamic_body做简单响应——它分配堆内存，对小响应是冗余开销
示例核心片段：
http::request<:string_body> req;
http::read(stream, buffer, req); // 自动等待完整请求
if (req.target() == "/health" && req.method() == http::verb::get) {
http::response<:string_body> res{http::status::ok, req.version()};
res.set(http::field::server, "boost-beast");
res.body() = "OK";
res.prepare_payload();
http::write(stream, res);
}</:string_body></:string_body>
如何避免 async_accept + async_read 导致的连接泄漏
异步服务器最常踩的坑是：acceptor.async_accept(socket, ...) 成功后，没立刻为这个 socket 启动 async_read，导致连接空转、资源不释放。更隐蔽的是，在 lambda 回调里捕获了 shared_ptr<session></session>，但 session 对象自身又持有 socket 的 shared_ptr，形成循环引用。
性能影响：连接数上去后，内存持续增长，top 看 RES 列飙升，strace -e trace=epoll_wait 发现大量 idle fd。
- 每个新连接必须立即绑定生命周期管理：推荐用
std::shared_ptr<session></session>构造时传入io_context，并在析构中主动socket.close() - lambda 捕获列表写成
[self = shared_from_this()]，而非[this]，防止 session 提前析构后 this 悬空 - 不要在
async_read回调里直接递归调用do_read()——改用尾递归风格，即回调末尾再发一次async_read
为什么 http::response::set 之后必须调用 prepare_payload()
Beast 不会在 set() 时自动补全 Content-Length 或 Transfer-Encoding 头。如果你只写 res.body() = "hello" 然后 http::write，客户端可能永远等不到响应结束，尤其 curl 或浏览器会卡在 loading 状态。
原因在于 HTTP/1.1 规定：除非用 chunked 编码，否则必须声明 Content-Length；而 Beast 默认不设任何传输编码，也不自动计算长度——它把决策权留给你。
- 对已知长度的字符串响应，调用
res.prepare_payload()会自动插入Content-Length头 - 若 body 是动态生成的（如流式日志），需手动设
res.set(http::field::transfer_encoding, "chunked")，再用http::chunk_body类型 - 忽略此步的错误信息通常不报错，只是客户端收不到 EOF，表现为超时或连接重置
事情说清了就结束。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
