应使用线程池+std::promise包装getaddrinfo_a调用并挂起协程，缓存采用分段哈希表+惰性过期+二进制序列化addrinfo，避免指针跨线程失效与野指针；推荐复用boost::asio::thread_pool调度器。
如何用 std::coroutine 封装 getaddrinfo_a 实现异步 DNS 请求
Linux 下原生异步 DNS（getaddrinfo_a）不支持直接 await，必须配合 io_uring 或信号/轮询。但协程本身不处理系统调用阻塞，所以不能直接 co_await getaddrinfo_a(...)。正确做法是：用线程池 + std::promise 包装同步调用，再用 std::suspend_always 挂起协程，等线程完成后再恢复。
-
getaddrinfo_a是 glibc 提供的异步接口，但实际仍是同步调用封装（内部仍会阻塞），仅避免调用线程阻塞在 socket 上；真正无阻塞需用io_uring或libuv - 不要在协程中直接调用
getaddrinfo—— 它会阻塞整个协程调度器线程 - 推荐封装为
task<:vector>> resolve_hostname(std::string_view host, std::string_view service)</:vector>，内部交由线程池执行 - 注意
addrinfo结构需手动freeaddrinfo()，不能靠 RAII 自动释放（因为跨线程传递指针）
DNS 缓存该用什么数据结构和过期策略
缓存不是简单放个 std::unordered_map 就完事。要支持并发读写、TTL 过期、LRU 驱逐，还得避免锁争用。最简可行方案是：分段哈希表 + 单独清理线程 + 原子 TTL 时间戳。
- 键用
std::string拼接host + ":" + service + ":" + hints.ai_family（避免 IPv4/IPv6 混淆） - 值存
struct cache_entry { std::vector<:byte> raw_data; std::atomic<time_t> expires_at; }</time_t></:byte>—— 把addrinfo序列化成二进制，避免指针跨线程失效 - 不依赖
std::shared_mutex（C++17 不保证无锁），改用std::shared_timed_mutex+ 读多写少场景下读锁粒度控制到 bucket 级 - TTL 从响应中解析
ai_canonname无效，得靠 DNS 响应包里的 TTL 字段 —— 所以必须用底层 DNS 协议栈（如ldns或dns-async），getaddrinfo_a不提供该信息
为什么不能靠 std::chrono::steady_clock 定时清理缓存
定时器精度和唤醒开销会毁掉轻量级目标。每秒唤醒一次检查所有 key 是否过期，对高频解析场景（如每秒千次请求）就是灾难。
- 更合理的是「惰性过期」：每次读缓存时检查
expires_at.load() ，过期则丢弃并触发后台异步刷新 - 后台清理只做两件事：扫描最近 N 条写入记录（按 LRU list），移除过期项；不遍历全表
- 若用
std::this_thread::sleep_for做定时器，会阻塞协程调度器线程 —— 必须用io_uring的IORING_OP_TIMEOUT或epoll+timerfd - 别信“用
std::atomic_flag轮询时间” —— 浪费 CPU，且在容器环境里可能被调度器惩罚
协程调度器要不要自己写？
除非你明确需要细粒度控制（比如把 DNS 请求绑定到特定 IO 线程），否则直接复用已验证的调度器。自己写极易出错，尤其在线程切换和异常传播路径上。
-
boost::asio::thread_pool+boost::asio::use_awaitable是目前最稳的选择，它自动处理异常重抛、调度上下文捕获、取消传播 - 别用
std::jthread或裸std::thread启动协程 —— 缺少取消点和调度提示，co_await可能永远挂起 - 如果用了
liburing，优先走io_uring_submit_and_wait+co_await自定义awaiter，而不是模拟线程池 - 一个容易忽略的坑：
co_await返回前，必须确保addrinfo内存仍在有效生命周期内 —— 很多人在 promise.set_value() 后就 freeaddrinfo()，结果协程 resume 时访问野指针
double free 或 use-after-free。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
