Asio异步编程核心是“不等结果、先干别的”，依赖回调或协程驱动；Standalone版免Boost依赖，API与Boost.Asio一致；TCP客户端需管理socket/缓冲区生命周期，服务器用session封装连接，协程需C++20支持且返回awaitable类型。
用 Asio 做异步编程，核心是“不等结果、先干别的”，靠回调或协程驱动后续逻辑。Boost.Asio 和 Standalone Asio（即 asio 单头文件版）API 几乎一致，区别只在编译方式和依赖——Standalone 版无需 Boost 库，头文件包含即可用；Boost.Asio 需链接 boost_system（Windows 下还常要 ws2_32）。实战中选哪个取决于项目约束，功能上没差别。
异步 TCP 客户端：连接 + 发送 + 接收
典型流程：创建 socket → 异步 connect → 成功后 async_write → 再 async_read。所有操作都传入一个可调用对象（lambda、function 或绑定函数），作为完成时的回调。
- 确保 io_context 在整个生命周期内运行（比如用
io_context.run()或io_context.run_one()驱动） - socket 必须在回调执行期间保持有效（避免栈对象提前析构，建议 heap 分配或用 shared_ptr 管理）
- 读写缓冲区不能是局部栈变量（回调可能延后执行），推荐用
std::vector或std::array配合asio::buffer()
异步 TCP 服务器：接受连接 + 处理会话
服务器模式常用“accept → 创建新 session → 继续 accept”循环。每个客户端连接应封装为独立对象（如 session 类），持有 socket、缓冲区、io_context 引用，并负责自身生命周期管理。
- 监听 socket 调用
async_accept()，成功后把新 socket 移交给 session 对象 - session 内部发起
async_read()，读到数据后处理、再发async_write()，最后通常继续async_read()形成循环 - 避免在回调里直接 delete this；推荐用
shared_from_this()（需继承std::enable_shared_from_this）保证对象存活
协程支持（C++20 / asio::use_awaitable）
Asio 从 1.70+ 原生支持 C++20 协程（需编译器开启 /std:c++20 或 -std=c++20），用 co_await 替代回调，代码线性易读。
立即学习“C++免费学习笔记（深入）”；
- 函数返回类型必须是
asio::awaitable，且在io_context的协程调度器中启动（如co_spawn(io_ctx, my_handler(), asio::detached)） - 所有异步操作改用
co_await socket.async_connect(..., asio::use_awaitable)形式 - 错误通过
system_error抛出，可用 try/catch 捕获，比手动检查 error_code 更直观
常见坑与建议
异步编程容易因资源管理或执行顺序出错，以下几点高频踩坑：
-
io_context::run() 会阻塞直到无待处理任务——若只调一次就退出，后续回调不会执行；多线程可搭配
io_context::work防止提前结束 - 同一个 socket 不允许同时发起多个未完成的 async_read/write——必须等前一个完成回调返回后，再发下一个；否则行为未定义
-
跨线程调用需注意线程安全：io_context 本身不是线程安全的，但可通过
post()或dispatch()把任务安全投递到其执行上下文 - 调试时启用 Asio 日志（
ASIO_ENABLE_HANDLER_TRACKING宏）能清晰看到每个操作的触发与完成链路
基本上就这些。Standalone Asio 编译更轻量，Boost.Asio 生态更成熟；协程写法清爽但要求较新工具链；回调风格兼容性强，适合嵌入式或长期维护项目。选型看团队习惯和平台限制，底层机制是一样的。
