boost.beast不提供现成http客户端类，需手动组合tcp::resolver、tcp::socket、http::request与http::response_parser，配合async_read/async_write或c++20协程实现异步get请求，必须返回awaitable类型、显式处理error_code、禁用同步read/write、正确启用gzip解析。
Boost.Beast 本身不提供开箱即用的 http_client 类，所谓“轻量级 HTTP 客户端请求”，本质是手动组合 tcp::resolver、tcp::socket、http::request 和 http::response_parser，再配以异步或协程驱动——没有封装就等于没有魔法，你得亲手串起每一段。
怎么用 boost::asio::awaitable 写一个可 co_await 的 GET 请求
必须返回 boost::asio::awaitable<t></t>，不能是 void 或裸 std::string；整个链路要共用同一个 io_context 的 executor，并显式处理 error_code：
-
co_await resolver.async_resolve(host, "http", boost::asio::use_awaitable)—— DNS 解析必须异步，别用resolve同步阻塞 - 连接后调用
http::async_read(socket, buffer, parser, boost::asio::use_awaitable)，不是http::read - 响应体是
parser.get().body().data()，别直接访问parser.body()，它可能为空或未就绪 - gzip 响应需提前 wrap
zlib::flate_stream，否则parser会把压缩字节当明文解析，结果是乱码或解析失败
为什么 http::read 和 http::write 不能直接用在协程里
它们是同步阻塞函数，会卡死整个线程，彻底废掉协程的异步意义。真正该用的是带 async_ 前缀的版本，且必须传 boost::asio::use_awaitable（不是 net::use_awaitable，命名空间错会导致编译失败）：
-
http::async_read返回可等待对象，内部已适配awaitable协议 - 若误传
net::deferred或漏掉use_awaitable，编译器会报 “no matching function for call to ‘await_transform’” - 超时不能靠
std::this_thread::sleep_for，得用net::steady_timer+co_await timer.async_wait()配合 cancel
常见崩溃点：没检查 error_code 就访问 parser.body().data()
HTTP 请求失败不会抛异常，而是通过 error_code 返回。很多代码写成 auto resp = co_await http_get(...); std::cout ，但 <code>resp 可能根本没成功解析——比如网络断开、404、gzip 未解压、chunked 编码解析中途出错，此时 parser.is_done() 为 false，body().data() 指向未初始化内存，直接访问就是段错误。
- 必须先判断
ec == boost::system::errc::success - 再检查
parser.get().result() == http::status::ok - 最后确认
parser.is_done()为true才安全读取 body
最易被忽略的是：Beast 的 http::response_parser 不自动处理 Content-Encoding: gzip，你得自己接一层 zlib::flate_stream 并绑定到 socket 读取链路上——这步漏掉，90% 的线上 API（尤其云服务）返回的都是 gzip 压缩体，你拿到的只会是一堆二进制垃圾。
