std::expected 是专为错误传播设计的类型，内部存成功值 t 或错误值 e；与 std::optional 根本区别在于明确区分“失败（error）”和“空值（nullopt）”，后者无错误语义。
std::expected 是什么，和 std::optional 有什么根本区别
它不是“可选值”的升级版，而是专为错误传播设计的容器：内部要么存成功值 T，要么存错误值 E（比如 std::error_code 或自定义错误类型）。关键在于——std::expected 明确区分了“没结果”（error）和“结果为空”（如 std::optional<int></int> 的 nullopt），而 std::optional 压根不带错误语义。
常见误用现象：std::optional<int></int> 被用来表示“计算失败”，但调用方无法知道失败原因；换成 std::expected<int std::string></int> 后，错误信息直接随返回值携带，无需额外查 errno 或全局状态。
怎么写一个能返回错误的函数（C++23 实操写法）
别再靠返回码 + 输出参数或抛异常来传递错误——std::expected 让错误路径和成功路径在类型层面就对等。典型写法：
std::expected<int, std::error_code> parse_int(const std::string& s) {
try {
return std::stoi(s);
} catch (const std::invalid_argument&) {
return std::unexpected(std::make_error_code(std::errc::invalid_argument));
} catch (const std::out_of_range&) {
return std::unexpected(std::make_error_code(std::errc::result_out_of_range));
}
}注意点：
立即学习“C++免费学习笔记（深入）”；
-
std::unexpected是构造 error 分支的唯一标准方式，不能直接写return std::error_code{...} - 模板参数顺序固定：第一个是 success 类型（
T），第二个是 error 类型（E），反了编译不过 - 如果 error 类型是
void，那就退化成类似std::optional的行为，但语义仍是“操作可能失败”，不推荐
调用方如何安全取值、处理错误（避免 .value() 崩溃）
直接调 .value() 和 .error() 是危险操作：前者在含 error 时抛 std::bad_expected_access，后者在含 value 时未定义行为。必须先判断状态。
推荐做法：
- 用
if (auto result = parse_int("123")) { int x = *result; }—— 隐式转换为bool表示是否含 success 值 - 用
result.has_value()显式判断，比result.has_error()更符合直觉（因 success 是主路径） - 需要统一处理错误？用
result.transform([](int x) { return x * 2; })处理 success，或result.map_error([](auto e) { return e.message(); })转换 error
容易踩的坑：result.value_or(42) 看似方便，但它只适用于 error 类型可默认构造且你愿意忽略错误细节的场景——大多数真实业务里，丢掉错误信息等于埋雷。
和异常比，什么时候该选 std::expected
它不是异常替代品，而是“同步、零成本、显式错误流”的补充方案。适用场景很具体：
- 系统调用封装（如
open()、read()），错误码天然存在，抛异常反而增加开销和控制流复杂度 - 配置解析、序列化、协议解包等“预期会频繁出错”的环节，异常会导致栈展开开销不可控
- 嵌入式或实时环境，禁用异常时，
std::expected是 C++23 提供的唯一标准错误传播机制
性能提示：std::expected 对象大小通常等于 max(sizeof(T), sizeof(E)) + 1 字节（用于 tag），无动态分配；但若 T 或 E 是非 trivial 类型，移动/复制成本需实测——别想当然认为它一定比异常快。
兼容性提醒：GCC 13+、Clang 16+、MSVC 19.35+ 才完整支持；用 __cpp_lib_expected 宏检测，别只看 __cplusplus == 202302L。
