async_resolve 报 operation_not_supported 是因 resolver 未绑定 io_context，必须显式传入 io_context& 构造，否则异步引擎未初始化；同时需确保 io_context::run() 正在执行且生命周期长于 resolver。
async_resolve 为什么总是报 operation_not_supported
直接调用 resolver.async_resolve("google.com", "80") 却触发 operation_not_supported，大概率是 resolver 没绑定 I/O 上下文。Boost.Asio 的 ip::tcp::resolver（或 ip::udp::resolver）必须显式关联 io_context 实例，不能只构造不绑定。常见错误写法：
boost::asio::ip::tcp::resolver resolver;这会使用默认构造，底层未初始化异步引擎。正确做法是传入
io_context&：boost::asio::ip::tcp::resolver resolver(io_ctx);注意：C++17 后推荐用
boost::asio::ip::resolver_base::flags 控制行为，比如加 boost::asio::ip::resolver_base::numeric_service 可跳过服务名查表，避免 service_not_found。
如何同时解析 IPv4 和 IPv6 并按优先级取第一个可用结果
默认 async_resolve 会返回所有匹配记录（A + AAAA），但顺序不保证，且你可能只想用 IPv4 或优先尝试 IPv6。解决方法是分两次调用，或用 query 显式指定协议族：
auto query = boost::asio::ip::tcp::resolver::query("example.com", "https", boost::asio::ip::tcp::resolver::query::numeric_service);<br>resolver.async_resolve(query, handler);更稳妥的做法是分别发起两路解析，用 weak_ptr 或标志位控制“只取首个成功”逻辑。注意：不要在 handler 里直接调 io_context::stop()，否则可能中断另一路解析；建议用原子布尔 std::atomic<bool> resolved{false}</bool> 做竞态控制。
handler 中获取真实 IP 地址时，endpoint.address() 返回的是 v4-mapped v6 怎么办
在启用了 IPv6 的系统上，即使你查的是纯 IPv4 域名，async_resolve 返回的 endpoint 有时是 ipv4_mapped 格式的 IPv6 地址（如 ::ffff:142.250.191.14）。这不是 bug，而是系统默认行为。若需强制转为原生 IPv4，检查并转换：
if (endpoint.address().is_v6() && endpoint.address().to_v6().is_v4_mapped()) {<br> auto ipv4_addr = endpoint.address().to_v6().to_bytes();<br> // 最后 4 字节即 IPv4 地址<br>}或者更简洁：用 boost::asio::ip::make_address_v4(endpoint.address().to_v6().to_bytes().data() + 12)。但注意：某些网络栈（如 Windows 的某些配置）可能不支持 v4-mapped，此时应提前用 resolver::query::canonical_name 配合 host_name() 做 fallback。
线程安全与 io_context::run() 调用时机的关键细节
async_resolve 是异步发起，但 DNS 查询本身可能涉及阻塞式 getaddrinfo（取决于 Boost.Asio 编译选项和平台）。若你启用了 BOOST_ASIO_HAS_IOCP（Windows）或 BOOST_ASIO_HAS_EPOLL（Linux），底层会用非阻塞方式；否则默认走线程池模拟异步，此时必须确保 io_context 有至少一个线程在跑 run() 或 run_one()。常见疏漏：
- 在
main()里构造 resolver、发请求，却忘了调io_ctx.run()—— 请求永远不会回调 - 把
io_context声明为局部变量，handler 还没执行函数就退出，导致bad_weak_ptr - 多个线程共用同一个
io_context，但没调io_ctx.post()就直接在非 owner 线程访问 resolver
io_context 和 resolver 一起封装进类，run() 放在独立线程，handler 内只做数据提取和 post() 到业务线程。
实际项目中容易被忽略的是 resolver 的生命周期管理——它内部持有 io_context 引用，但不参与所有权；一旦 io_context 析构而 resolver 还活着，后续调用会 crash。务必让 resolver 的生存期短于 io_context，或用 std::shared_ptr 统一管理。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
