C++26 中不存在 std::net；实际可用方案为 POSIX socket、boost::asio、libuv 或 uvw，其中 boost::asio 是当前事实标准，支持 AOT 编译、协程与零成本抽象。
std::net 在 C++26 中根本不存在
截至 C++26 标准草案（N4971 及之前），std::net **未被纳入标准库**，也没有任何 AOT（Ahead-of-Time）网络库以该名称或形式成为 ISO C++ 标准的一部分。你在网上看到的 std::net 相关讨论，基本来自早期提案（如 P1157R0）、实验性分支（如 libstdc++ 的私有试验）、或混淆了其他语言（如 Rust 的 std::net）。
C++26 实际可用的网络编程路径只有这几种
目前 C++26 提案中与网络最相关的是 std::networking（原 P2116R0 提案），但它仍处于 TS（Technical Specification）预备阶段，**未冻结、未合并、编译器完全不支持**。真实可行的方案只有：
- 用 POSIX
socket()/bind()/connect()+poll()/epoll()（Linux）或WSA*（Windows）——最直接，但跨平台需封装 - 基于
std::thread+std::async封装阻塞 socket，适合简单工具，但无法应对高并发 - 采用成熟第三方库：如
boost::asio（头文件模式可 AOT 编译）、libuv（C 接口，C++ 封装成熟）、uvw（现代 C++17 封装） - 若坚持“标准感”，可尝试
std::experimental::net（仅 GCC 13+ libstdc++ 启用-fmodules-ts且带--enable-libstdcxx-experimental编译时才可能有极简雏形，但无文档、无保证、不可用于生产）
为什么别等 std::net，现在就用 boost::asio
boost::asio 是当前事实标准，它满足你隐含的所有诉求：
- AOT 友好：纯头文件 + 可选静态链接
boost_system，无运行时 JIT 或解释器依赖 - C++26 兼容：完全支持 C++20/23 概念、coroutine（
co_awaitonasio::awaitable） - 零成本抽象：底层仍是
epoll/kqueue/IOCP，性能贴近裸 socket - 错误处理清晰：
asio::error_code避免异常开销，也支持 throw 版本
例如一个非阻塞 TCP 客户端连接片段：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
asio::io_context ctx;
asio::ip::tcp::socket sock(ctx);
sock.async_connect(
asio::ip::tcp::endpoint{asio::ip::make_address("127.0.0.1"), 8080},
[](const asio::error_code& ec) {
if (!ec) std::cout << "connected\n";
}
);
ctx.run();
容易被忽略的兼容性陷阱
即使你决定自己封装 socket，这几个点常被跳过导致线上故障：
-
SO_REUSEADDR必须在bind()前设置，否则重启服务时 “Address already in use” —— 即使进程已退出，TIME_WAIT 状态仍占端口 - IPv4/IPv6 双栈需显式设
IPV6_V6ONLY=0，否则AF_INET6socket 默认不接受 IPv4 映射地址 - Linux 上
send()返回EAGAIN/EWOULDBLOCK是正常流程，不是错误；而 Windows 的WSAEWOULDBLOCK语义等价，但值不同——跨平台必须用errno或WSAGetLastError()分支判断 - 读取时不能假设一次
recv()拿到完整应用层消息：TCP 是字节流，需自行处理粘包/拆包（如加长度头、分隔符）
标准不会替你做这些事，也没打算做。等 std::net 不如今天就写个 socket_wrapper.h 把上述逻辑收拢。
