getaddrinfo 本身不支持超时，必须通过异步封装（如 std::async + wait_for）或线程池实现可控超时；需避免跨线程复用 hints、超时后禁止 freeaddrinfo、Windows 应改用 GetAddrInfoEx；批量解析须加 jitter 和协议族过滤。
getaddrinfo 本身不支持超时，得自己包一层
getaddrinfo 是阻塞调用，没有超时参数，直接在主线程里批量调用会卡死。Linux/macOS 下它底层可能触发 DNS 查询（比如走 res_query），而 glibc 的 resolver 默认无超时或超时长达数秒，且无法 per-call 控制。所以不能指望靠改 /etc/resolv.conf 或 setenv("RES_OPTIONS") 来救——那些是全局生效、不线程安全、还容易被其他库覆盖。
实操上必须把 getaddrinfo 放进独立线程或子进程，再用 pthread_cancel / std::thread::join_for / poll + AF_UNIX socket 通知等机制做超时裁决。更稳妥的是用 std::async 配合 std::future::wait_for：
auto fut = std::async(std::launch::async, []() {
addrinfo* result = nullptr;
int ret = getaddrinfo("example.com", "80", &hints, &result);
return std::make_pair(ret, result);
});
if (fut.wait_for(2s) == std::future_status::ready) {
auto [ret, res] = fut.get();
// 处理结果
} else {
// 超时，注意：res 可能未分配，不能 freeaddrinfo
}并发量大时别裸用 std::thread，优先选线程池 + 异步回调
每域名起一个 std::thread 看似简单，但 1000 个域名就 1000 个线程，栈内存暴涨、上下文切换开销大，glibc 的 getaddrinfo 内部还有锁（比如 __res_maybe_init），实际并发度远低于预期，甚至出现大量超时假阳性。
建议用固定大小的线程池（比如 16～32 线程），每个任务封装为 lambda 提交到队列；同时避免在回调里直接 freeaddrinfo ——若超时后线程仍在执行 getaddrinfo，此时 free 会 crash。正确做法是让 worker 线程自己负责 freeaddrinfo，或者用 std::shared_ptr 管理生命周期：
立即学习“C++免费学习笔记（深入）”；
- 传入的
hints必须在线程内 copy，不能共享指针到栈变量 - 返回的
addrinfo*必须由执行getaddrinfo的同一线程释放 - 超时后不要尝试 cancel 线程（
pthread_cancel不安全，C++ 标准不保证可取消点）
Windows 上 getaddrinfo 超时行为更不可控，得换招
Windows 的 getaddrinfo 在旧版本（如 Win7）中会无视系统 DNS 超时设置，卡住 15 秒以上；即使在 Win10+，它仍可能受注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters 中 MaxCacheEntryTtlLimit 等项影响，且无法 per-call 覆盖。
更可靠的做法是绕过 getaddrinfo，改用 Windows Sockets 的异步 API：WSAAsyncGetHostByName 已废弃，推荐用 GetAddrInfoEx + OVERLAPPED + I/O completion port，或直接投喂 std::jthread + WaitForSingleObject 等待事件句柄。注意：GetAddrInfoEx 的 dwTimeout 参数单位是毫秒，但实际精度受系统定时器分辨率限制（通常 15.6ms），别设低于 50ms 的超时。
批量解析时别忽略 DNS 响应节流和本地缓存干扰
连续发几十个 getaddrinfo 请求，很可能触发本地 DNS 缓存未命中 → 向上游服务器发包 → 遭遇 rate limiting（尤其用公共 DNS 如 8.8.8.8）。现象是部分请求延迟突增至数秒，不是代码写错了，而是网络层被限速了。
缓解方式很简单但常被跳过：
- 加随机 jitter（比如 ±100ms）再提交任务，打散请求时间戳
- 用
AI_ADDRCONFIG标志过滤掉当前不活跃的协议族（如无 IPv6 接口时跳过 AAAA 查询） - 首次失败后，对同一域名降级重试：先查 A 记录，失败再查 AAAA，避免双查放大延迟
- 别复用同一个
addrinfo hints结构体跨线程——某些平台（如 musl）会修改其内部字段
真正难的不是并发模型，而是怎么让 getaddrinfo 在不同系统、不同 libc、不同网络环境下都给出可预测的响应时间。超时值设太短丢请求，设太长拖垮整体耗时，中间那个平衡点得靠真实环境压测，不是看文档就能定的。
