async_wait 配合 steady_timer 实现超时控制需确保 timer 与 socket 同属一个 io_context，超时调用 cancel() 使操作以 boost::asio::error::operation_aborted 结束，并在回调中显式判断该错误码以区分真实失败；需避免循环引用、use-after-free 及跨平台错误码误判。
async_wait 配合 steady_timer 实现超时控制
Boost.Asio 本身不给 async_read、async_write 这类 I/O 操作直接加超时参数，得靠 steady_timer 主动取消。核心思路是：启动一个异步等待（比如读 socket），同时启动一个 steady_timer，超时就调用 socket.cancel() 或 timer.cancel() 触发对应操作的完成处理，让回调能收到 boost::asio::error::operation_aborted。
注意：必须在同一个 io_context 上运行 timer 和 socket，否则 cancel 可能无效；且 timer 的 async_wait 回调里不能直接销毁 socket 或 timer 对象，容易引发 use-after-free。
- 推荐用
steady_timer而非system_timer，避免系统时间跳变干扰超时逻辑 - timer 的
expires_after应在async_wait前调用，否则可能因调度延迟导致“刚设完就超时” - 如果 socket 已经完成（比如数据秒到），timer 仍在 pending，需在 I/O 回调里显式调用
timer.cancel()防止误触发
cancel() 后的错误码判断必须检查 operation_aborted
调用 socket.cancel() 不会抛异常，而是让所有 pending 的异步操作以 boost::asio::error::operation_aborted 结束。但这个错误码和网络断连、连接拒绝等真实错误混在一起，必须显式区分，否则会把超时当成失败重试。
典型错误写法是只检查 !ec 就认为成功，漏掉超时场景；正确做法是在回调里先判断 ec == boost::asio::error::operation_aborted，再决定是否报超时。
立即学习“C++免费学习笔记（深入）”；
-
async_read完成时若ec.value() == 125（Linux 下ECANCELED映射值），大概率是被 cancel 导致的，但跨平台应始终用boost::asio::error::operation_aborted比较 - 不要依赖
bytes_transferred == 0判断超时——正常读到 0 字节（如对端 close）也会这样 - 如果用了
async_read_some，超时后仍可能有部分数据已接收，需结合缓冲区状态做清理
避免 shared_ptr 循环引用导致 timer/socket 泄露
常见模式是把 socket 和 timer 都塞进同一个 std::shared_ptr 对象（比如 handler 类），然后传给 async_wait 和 async_read。但如果 timer 回调里又捕获了这个 shared_ptr，就形成循环引用：handler → timer → handler，结果对象永远不析构。
解决方案是 timer 回调中用 weak_ptr 持有 handler，或把 timer 生命周期绑定到 socket 上（例如 timer 是 socket 的成员变量），或改用裸指针 + 外部生命周期管理（需确保 cancel 时机可控）。
- 用
std::enable_shared_from_this时，务必确认shared_from_this()调用前对象已被make_shared构造，否则抛bad_weak_ptr - timer 析构前必须已 cancel，否则 pending 的 async_wait 可能访问已释放内存
- 如果 handler 是 lambda，捕获
[self = shared_from_this()]是安全的，但别写成[self](...){ self->... }后续又让 self 离开作用域
async_connect 的超时要特别处理 EINPROGRESS 场景
async_connect 在非阻塞 socket 上实际是“发起连接并立即返回”，底层可能返回 EINPROGRESS，Asio 会内部等待可写事件。此时若 timer 超时调用 socket.cancel()，Linux 下通常返回 operation_aborted，但某些旧内核或 Windows 可能返回 connection_refused 或 network_unreachable，看起来像真实失败。
更稳妥的做法是：connect 回调里检查 ec，若为 boost::asio::error::in_progress（即 EINPROGRESS），说明还在连，才启用 timer；否则直接走错误分支。
- 不要对
async_connect直接套 timer 后 cancel，容易掩盖真实的连接拒绝原因 - Windows 下
CancelIoEx对 connect 的支持不如 Linux 的close彻底，建议测试目标平台行为 - 如果 connect 成功但后续 handshake（如 TLS）卡住，需另起 timer 控制 handshake 超时，不能复用 connect 的 timer
超时机制真正难的不是写几行 cancel，而是 cancel 后的状态一致性——socket 是否还可用、缓冲区有没有残留数据、timer 和 handler 的生命周期谁管谁、错误码怎么归因。这些细节不抠清楚，线上就容易出现连接假死、内存泄露或超时误判。
