C++ 标准库长期没有网络库，虽然从 C++11 开始就有相关提案，但至今（C++23/26）仍未成功标准化。这主要是标准化进程、技术争议和优先级竞争的结果。
1. 标准化进程的坎坷（Asio 的曲折之路）
目前 C++ 网络库的事实标准是 Asio（也 Boost.Asio），它由 Chris Kohlhoff 开发。其标准化历程堪称"马拉松"：
| 时间 | 进展 |
|---|---|
| 2005 | 作为 Boost.Asio 发布，开始准备进入标准 |
| 2014 | 提出 Networking TS（ISO/IEC TS 19216:2018），计划进入 C++17 |
| 2017 | C++17 拒绝：因 executor（执行器）设计争议，被移出 C++17 |
| 2018 | Networking TS 正式发布，但仍是"技术规范"而非标准 |
| 2020 | C++20 再次错过：未能在截止前解决设计问题 |
| 2021 | 计划并入 C++23，但出现协程兼容性问题 |
| 2023 | C++23 正式撤回：委员会投票决定将网络库从 C++23 草案中移除 |
2. 核心技术争议
阻碍进入标准的主要技术分歧：
A. Executor（执行器）模型争议
Asio 的核心是 io_context 和 executor 机制，但委员会对"执行器"的抽象设计长期无法达成一致：
- 回调模型 vs futures/promises
- 如何与 C++20 协程（Coroutines）无缝集成
- 执行器的定制性和性能边界
B. 协程兼容性危机（致命一击）
当 C++20 引入协程后，Networking TS 基于回调的设计显得过时。重写为协程风格需要大量工作，而 C++23 的截止期限迫近，最终导致撤回。
C. 平台抽象复杂度
虽然 Asio 已解决跨平台问题，但委员会担心：
- IOCP（Windows）vs epoll/kqueue（Unix）的差异如何抽象
- SSL/TLS 是否应包含（涉及加密标准，政治敏感）
- 命名解析（DNS）的阻塞/非阻塞边界
3. 优先级竞争与资源限制
C++ 标准委员会更关注语言核心特性：
- C++11：右值引用、lambda、并发内存模型（奠定了基础但没时间做网络）
- C++14/17：概念、constexpr、文件系统（
std::filesystem优先于网络） - C++20：概念（Concepts）、范围（Ranges）、协程、模块（Modules）
- C++23：std::print、flat_map、expected、mdspan
网络库始终排在这些基础组件之后。
4. 现状与替代方案
当前状态：
- C++23/26 没有
std::net或类似组件 - Networking TS 仍可作为独立技术规范使用（需单独实现）
- 新的提案 "std::execution"（P2300）可能先进入标准，为未来网络库提供基础
实际开发选择：
// 必须使用第三方库
#include <boost/asio.hpp> // 最主流，准标准
#include <asio.hpp> // 独立版本（header-only）
// 或
#include <curl/curl.h> // libcurl，C 风格但成熟
#include <httplib.h> // cpp-httplib，轻量级
总结
C++ 没有标准网络库不是因为技术不可能，而是因为标准化委员会对设计的完美主义追求与语言进化速度的错配。每次接近标准时，语言本身又引入了新范式（如协程），导致网络库需要重新设计，形成"永远的下一个标准"的循环。
相比之下，Rust 在 1.0 时就包含了基础的 std::net（虽然简单但可用），而 Go 更是将网络作为语言核心（goroutine + channel），这反映了不同语言的设计哲学差异。