std::expected 在错误路径上避免栈展开开销，通过内联存储错误值实现无异常分支跳转，适用于高频调用、实时敏感及 -fno-exceptions 环境，并支持链式组合与值语义操作。

std::expected 在错误路径上避免栈展开开销

传统 throw / catch 触发时，C++ 运行时必须执行栈展开（stack unwinding），逐层调用析构函数并查找匹配的 catch 块。这在高频调用、实时敏感或无异常环境（如 -fno-exceptions）中代价显著。std::expected 将错误值内联存储在对象中，value() 或 and_then() 等操作全是普通分支跳转，无栈展开，也不依赖 RTTI。

实操建议：

• 若函数失败是常见路径（例如解析配置、读取可选字段），用 std::expected 比抛异常更符合实际控制流
• 启用 -fno-exceptions 时，std::expected 是少数能表达“可恢复错误”的标准方案
• 注意：std::expected 的 T 和 E 必须是可移动（或可复制）且非 void；若需表示“无返回值 + 可能失败”，用 std::expected

std::expected 支持链式错误传播与组合

异常无法被“携带”或“延迟处理”——一旦抛出，控制权立即跳出当前作用域。而 std::expected 是值语义类型，可被存储、传参、返回、嵌套，并天然支持函数式组合操作。

例如，你可把多个可能失败的操作串成管道，每个环节只关心自己的输入输出，错误自动向下游传递：

auto parse_int(std::string_view s) -> std::expected {
    try { return std::stoi(std::string{s}); }
    catch (...) { return std::unexpected("invalid integer"); }
}
auto square(int x) -> std::expected {
if (x > 10000) return std::unexpected("too large");
return x * x;
}
// 组合：parse_int("42").and_then(square) → std::expected

关键点：

• and_then 只在含值时调用回调，否则直接透传错误；无需手动写 if (e.has_value())
• transform 和 transform_error 分别映射成功值和错误值，适合统一错误码、添加上下文
• 不能直接用 operator|（像 Rust 的 ?），但可通过 ADL 扩展或封装辅助函数模拟

与 status-code 类型（如 absl::Status）相比的内存与 ABI 约束

std::expected 是标准库提供的泛型容器，其大小至少为 max(sizeof(T), sizeof(E)) + 1 字节（用于存放 tag），不引入额外指针或堆分配。而某些 status 类型（如 absl::Status）内部持有堆分配的 message 字符串，带来间接访问和生命周期管理成本。

但要注意：

• E 若很大（如含长字符串或嵌套结构），会拖慢 std::expected 的拷贝/移动；此时应考虑用 std::expected> 或自定义轻量错误枚举
• 目前（GCC 13/Clang 17）对 std::expected 的优化尚不成熟，某些链式调用可能未完全内联；建议在关键路径做 profile 验证
• 跨编译单元传递 std::expected 时，确保所有模块使用相同标准库实现（尤其是 MSVC 的 std::expected 实现细节与其他编译器不同）

std::expected 不替代异常的场景

它不是万能错误处理方案。以下情况仍应坚持用异常：

• 资源获取失败且无法局部恢复（如 new 失败、线程创建失败）——这类错误通常意味着程序状态已不可靠
• 需要跨多层抽象边界“向上冒泡”且中间层完全不关心错误细节（异常的动态分发机制更合适）
• 已有大量异常驱动的代码库，强行改用 std::expected 会破坏接口契约和调用方假设

真正容易被忽略的是：错误类型的可组合性不等于可读性。std::expected 虽灵活，但 std::string 错误值无法参与 switch 或静态分析；生产环境更推荐用强类型错误枚举（如 enum class ParseError）作为 E。