最稳妥的选择是boost::asio 1.78+搭配ip::tcp::resolver或ip::udp::resolver；需启用awaitable模式、绑定io_context、用use_awaitable令牌；缓存应基于host:port键并按TTL自动清理；协程取消需显式调用cancel()并配合超时丢弃，同时实现in-flight查询去重。
协程异步 DNS 解析该用哪个库
标准 C++20 不提供 DNS 解析能力，std::coroutine 本身也不处理网络 I/O。必须依赖第三方异步网络库，且该库需同时支持协程和 DNS 查询。目前最稳妥的选择是 boost::asio 1.78+（含 awaitable 支持）搭配其内置的 ip::tcp::resolver 或 ip::udp::resolver；libcurl 虽支持异步，但原生不暴露协程接口，需自行封装 awaiter，容易出错；uvw 和 cpp-httplib 均无 DNS 解析协程 API。
关键点：不要试图用 getaddrinfo + poll 手写协程化——DNS 查询涉及多个 UDP 包重试、TCP 回退、EDNS 处理等，底层复杂度远超 socket 读写。直接用 asio::ip::basic_resolver 的 async_resolve 是唯一可维护路径。
如何让 resolver 调用真正异步且可 co_await
asio::ip::tcp::resolver 的 async_resolve 默认返回 void，不能直接 co_await。必须启用 awaitable 模式：在包含头文件前定义 BOOST_ASIO_ENABLE_HANDLER_TYPE_REQUIREMENTS，并使用 asio::use_awaitable 作为完成令牌。
- 确保
asio::io_context在协程执行期间持续运行（不能被析构或stop()） - resolver 实例必须绑定到同一个
io_context，且生命周期 ≥ 协程生命周期 - 调用时传入
asio::use_awaitable，而非自定义 handler；否则协程挂起逻辑不生效 - 示例片段：
auto endpoints = co_await resolver.async_resolve( asio::ip::tcp::resolver::query{"example.com", "http"}, asio::use_awaitable);
过期自动清理怎么避免内存泄漏和重复查询
DNS 缓存过期不是靠定时器轮询，而是靠“首次查询后启动延迟任务”，并在下次查询命中缓存时刷新 TTL。手动管理 std::shared_ptr + weak_ptr 容易漏掉协程栈帧中的引用，导致缓存项永远不释放。
立即学习“C++免费学习笔记（深入）”；
- 用
std::unordered_map<:string std::pair>, std::chrono::steady_clock::time_point>></:string>存缓存，key 为 host:port 组合字符串 - 每次
co_await resolve前先查缓存：若存在且未过期（当前时间 - TTL 来源必须取自 DNS 响应中的
rr->ttl()，不能硬编码；asio::ip::tcp::resolver::results_type不暴露 TTL，需换用asio::ip::udp::resolver并解析原始响应，或改用dns-cpp库配合 asio - 缓存清理不依赖独立线程：在每次查询入口检查并删除过期项即可，避免竞态
协程取消和 DNS 查询中断的实际表现
协程被 co_await 中断时，asio::ip::tcp::resolver::async_resolve 不会自动取消底层 DNS 请求——它已发往系统 resolver 或上游 DNS 服务器，只能等待完成或超时。这会导致“幽灵查询”堆积。
- 必须显式调用
resolver.cancel()，但仅对未完成的异步操作有效；已发出的 UDP 查询无法撤回 - 更可靠的做法是给每个查询设置
asio::detail::deadline_timer，超时后主动丢弃结果（即使 DNS 响应后来到达） - 若业务要求强一致性（如服务启停时彻底终止所有 DNS 请求），需在
io_context::stop()前遍历所有活跃 resolver 实例并调用cancel() - 注意：
resolver.cancel()可能触发 handler 以asio::error::operation_aborted完成，协程中需捕获该错误而非崩溃
真正麻烦的是 TTL 精度和并发查询去重——同一 host 的多次并发请求，如果没做 in-flight 查询去重，可能触发 N 次相同 DNS 请求。这个逻辑不在 asio 范围内，得自己用 std::shared_mutex + std::map 管理 pending promise，稍有不慎就 deadlock 或 race。
