io_context::run() 会立刻返回是因为没有 pending 的异步操作或未消费的任务；需用 executor_work_guard 维持运行状态，且每个调用 run() 的线程都应拥有独立实例。
io_context::run() 为什么会立刻返回？
io_context::run() 的设计逻辑是：只要没有 pending 的异步操作（包括未完成的 async_connect、async_read、async_wait，或未被消费的 post/dispatch 任务），它就会立即退出 —— 这不是 bug，是行为契约。常见错误现象是：先调 run()，再发请求，结果主线程直接往下走，连接根本没发出去。
用 executor_work_guard 维持运行状态
最直接的办法是构造一个 executor_work_guard 对象，绑定到 io_context，让它“认为还有活儿干”。它不执行任何实际工作，只防止 run() 因为空闲而退出。
-
auto work = asio::make_work_guard(ioc);是推荐写法（C++17 起，类型推导更安全） - 旧式写法
asio::io_context::work work{ioc};在较新版本中已弃用，编译可能报 warning - work 对象必须在
run()调用前构造；析构时（如离开作用域或显式reset()）会解除保护，之后若无新任务，run()下次就会退出 - 多线程场景下，每个调用
run()的线程都应有自己的work实例（见线程池实现）
多线程中如何避免某线程提前退出？
当多个线程同时调用同一个 io_context::run() 时，仅靠一个全局 work 不够 —— 因为 work 是 per-io_context 的，不是 per-thread 的。正确做法是为每个线程配一个 executor_work_guard：
- 每个线程启动前，调用
make_work_guard(ioc.get_executor()) - 把 guard 存入
std::vector<:unique_ptr>>管理，确保生命周期覆盖整个线程运行期 - 停止时先
reset()所有 guard，再stop()或等待run()自然返回 - 漏掉任一 guard 的
reset()，都会导致对应线程卡在run()中无法退出
替代方案：post 一个空任务也行，但不推荐
有人用 asio::post(ioc, []{}); “骗” run() 继续跑，这确实能阻止退出，但有明显缺陷：
- 该任务执行完就没了，不能自动续命；需手动循环
post，易出错 - 引入无意义调度开销，尤其高并发时影响可观
- 无法与
stop()协同：stop()会中断所有 pending 操作，但空 lambda 已执行完毕，无法作为退出信号 - 语义不清，后续维护者很难一眼看出这是“保活”意图
真正需要长期运行的事件循环，executor_work_guard 是唯一清晰、轻量、符合 Asio 设计哲学的解法。容易忽略的是：它必须和 run() 在同一作用域生命周期内管理，否则要么提前失效，要么阻碍正常退出。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
