std::expected 是 C++23 引入的值语义错误处理工具，本质是 std::variant<T, E> 的封装，适合替代错误码而非异常，用于需显式传播错误但禁用异常的场景（如嵌入式、系统调用），不适用于需栈展开或不可恢复错误。
std::expected 是什么，它适合替代异常还是错误码？
std::expected 是 C++23 引入的值语义错误处理工具，本质是 std::variant<T, E> 的封装，其中 T 是成功值类型，E 是错误类型（通常为 std::error_code 或自定义错误枚举）。它既不抛异常，也不靠返回码隐式判断，而是把「结果」和「错误」都显式打包进一个对象里。
它适合替代「需要明确传播错误但又不想用异常」的场景，比如嵌入式、游戏引擎底层、系统调用封装、异步 I/O 回调链。不适合替代异常的场景：需要栈展开清理资源、错误不可恢复且应立即中止流程。
常见误用是把它当 bool 用——只检查 has_value() 就丢掉 error()，这等于把错误码又变回了“忽略型错误码”。
如何从函数返回 std::expected 并保持调用链清晰？
关键不是“怎么返回”，而是“怎么让调用方不用写一堆 if (!res.has_value())”。推荐组合使用 and_then（C++23）和手动解包逻辑。
立即学习“C++免费学习笔记（深入）”；
-
and_then接收一个std::expected<U, E> (T&&)形式的函数，自动在has_value() == true时调用，并透传错误；失败时直接短路返回原错误 - 避免裸写
res.value()—— 它会throw std::bad_expected_access，除非你确定已检查过 - 对可预期的错误（如文件不存在），优先用
error()获取后做分支；对意外错误（如std::errc::io_error），可转为std::unreachable()或日志后 abort
std::expected<int, std::errc> parse_int(std::string_view s) {
char* end;
long v = std::strtol(s.data(), &end, 10);
if (*end != '\0') return std::unexpected{std::errc::invalid_argument};
if (v < INT_MIN || v > INT_MAX) return std::unexpected{std::errc::result_out_of_range};
return static_cast<int>(v);
}
<p>auto res = parse_int("42")
.and_then([](int i) -> std::expected<int, std::errc> {
if (i < 0) return std::unexpected{std::errc::invalid_argument};
return i * 2;
});
// res 是 std::expected<int, std::errc>，无需手动判空std::expected 和 std::error_code 配合时要注意哪些陷阱？
std::expected<T, std::error_code> 是最常用组合，但容易踩三个坑：
- 不要直接用
std::make_error_code构造泛型错误——它不保证跨编译单元唯一性；应统一用std::errc或自定义std::error_category -
std::error_code默认可隐式构造，导致std::expected<int, std::error_code>{42}编译通过，但其实是把42当作 error 构造了！务必显式用std::expected<int, std::error_code>{std::in_place, 42}或直接写std::expected<int, std::error_code>{42}仅当 T 可隐式转换自 int（不推荐） - 比较两个
std::error_code要用==，不是.value() ==—— 后者忽略 category，可能误判（例如std::errc::no_such_file_or_directory和 Windows 的ERROR_FILE_NOT_FOUND值相同但 category 不同）
什么时候不该用 std::expected？
它不是银弹。以下情况建议退回更轻量或更重的方案：
- 函数只可能失败一次且调用方必定要处理（如打开配置文件），用
std::optional<T>+ 独立错误日志更简单 - 错误类型太多、需要动态派发（如网络协议多层错误码映射），
std::variant<E1, E2, E3>比std::expected<T, E>更灵活，但失去值语义一致性 - 已有成熟异常体系（如大型服务端框架），强行改用
std::expected会割裂错误处理风格，增加心智负担 - 性能敏感路径（如 inner loop 中频繁创建
std::expected），注意其移动构造/赋值仍有开销，比纯int返回码重
最常被忽略的一点：std::expected 的真正价值不在单个函数，而在整条调用链的错误透明传递。如果只有出口函数检查错误，中间全用 .value() 强解，那和裸指针解引用没区别——崩溃只是早晚问题。
