C++26 不包含 std::execution（P2300），该提案已在 2024 年 Kona 会议被 WG21 正式否决；主因是范围失控与实现脱节，主流标准库尚无符合语义的运行时支持。
std::execution（P2300）**不会落地**——它已被 WG21 在 2024 年 2 月的 Kona 会议上正式否决，**不会成为 C++26 的一部分**。
这意味着：你不需要为“C++26 的 Sender/Receiver 模型”做任何迁移准备，它目前不存在于标准时间线中。
为什么 P2300 被拒绝？
核心问题不是技术不成熟，而是“范围失控 + 实现脱节”：
-
sender/receiver原本想统一异步操作（如std::async、协程 awaitables、网络 I/O），但最终提案膨胀到必须重定义执行器（executor）、调度语义、错误传播、取消机制，甚至影响std::thread和std::jthread的抽象层 - 主流实现（libstdc++、libc++）明确表示：没有可交付的、符合 P2300 语义的运行时支持；LLVM 和 GCC 团队也未承诺在 C++26 周期内完成实验性实现
- 委员会判断：强行塞入 C++26 会导致标准与现实脱钩，损害可信度
那现在该用什么？
当前可行路径非常明确：
- 协程仍是首选：用
co_await+ 自定义awaiter封装任意异步源（如 libuv、asio、WinRT），稳定、可调试、编译期检查强 - 第三方库继续主导：
boost::asio（v1.83+ 已深度集成 sender/receiver-like 语义，但不依赖 P2300）、facebook/folly、Microsoft/cppwinrt都提供生产级异步原语 - 标准库仅提供基础构件：C++20 的
std::jthread、std::latch/std::semaphore、C++23 的std::stacktrace和改进的std::format，用于辅助而非驱动异步流
Sender/Receiver 还有未来吗？
有，但路径已重置：
- P2300 被拆解为多个更小的 TS（Technical Specification）草案，例如：
- P2955（
std::task简化协程包装） - P2976（轻量级
sender概念，不绑定执行器） - P3174（取消语义标准化，独立于 sender）
这些新提案将单独评审，最早可能进入 C++29 或更晚的 TS，且每个都要求已有两个以上可互操作的实现
- P2955（
- 关键信号：ISO C++ 官方 GitHub 仓库中，
std::execution模块已从 C++26 tracking issue 中移除，归档至 “Deferred” 标签
// 当前最接近“标准 sender”风格的合法写法（C++23，无需 P2300）
#include <coroutine>
#include <future>
template<typename T>
struct task {
struct promise_type {
T value_;
std::exception_ptr ex_;
auto get_return_object() { return task{}; }
auto initial_suspend() { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_value(T v) { value_ = std::move(v); }
void unhandled_exception() { ex_ = std::current_exception(); }
};
};
真正要警惕的，不是“怎么用 sender”，而是误信某些博客或会议幻灯片里“C++26 已包含 P2300”的过时信息——标准进程是公开、缓慢、高度保守的，所有变更都能在 cplusplus/papers 里查到原始记录。 
