std::expected适合替代文件打开、JSON解析、配置读取等预期可能失败且需显式处理的同步操作错误码；不适用于异常拦截或析构函数中，链式调用需区分and_then（下一步可能失败）与transform（纯转换）。
std::expected 适合替代哪些错误码场景
它不是万能的异常替代品，只适合「预期中可能失败、且调用方必须显式处理」的同步操作。比如文件打开、JSON 解析、配置读取——这些本就该返回 std::expected<T, E>，而不是靠 errno 或自定义 int 错误码硬编码。
常见错误现象：有人把 std::expected<void, std::error_code> 当成“带错误信息的 void 函数”，结果发现链式调用时 and_then 无法推导类型，编译报错 no matching function for call to 'and_then'。
- 使用场景：函数有明确成功值（如
std::string）、失败时需携带上下文（如std::errc::no_such_file_or_directory），且调用方不希望 throw 或检查全局状态 - 参数差异：第一个模板参数是成功类型（可为
void），第二个是错误类型（必须可复制，不能是std::exception_ptr——那是std::expected<T, std::exception_ptr>的事） - 性能影响：无堆分配，和
std::optional类似，比抛异常轻量；但比裸int错误码多几个字节（含状态标记位）
std::expected 和异常共存时怎么写才不混乱
别试图用 std::expected 拦截所有异常。C++23 标准没禁止你在 std::expected 构造函数里 throw，但一旦 throw，就违背了它的设计意图：让错误路径变得可见、不可忽略。
容易踩的坑：在 and_then 回调里抛异常，导致外层调用者既得检查 has_value()，又得套 try/catch——这比原来还糟。
立即学习“C++免费学习笔记（深入）”；
- 推荐做法：底层函数（如系统调用封装）返回
std::expected；上层业务逻辑根据需要决定是否转成异常（例如用value()强解，触发内部 throw） - 兼容性注意：
std::expected的value()在无值时 throwstd::bad_expected_access，不是你自定义的异常类型，别依赖其派生关系 - 不要在析构函数、
noexcept函数里调用value()或error()——它们都不标noexcept
std::expected 链式调用（and_then / transform）的边界条件
and_then 不是 std::optional 的简单复刻，它对返回类型的约束更严格：回调必须返回另一个 std::expected，否则编译失败。而 transform 要求回调返回非 expected 类型（会自动包一层）。
典型错误：写 e.and_then([](int x) { return x * 2; })，编译器报 cannot convert 'int' to 'std::expected<...>' ——这里该用 transform。
-
and_then：用于“下一步也可能会失败”的操作，比如解析完 JSON 对象后，再从中取字段（也可能不存在） -
transform：用于“确定成功后的纯转换”，比如把读到的std::vector<char>转成std::string - 嵌套深了容易晕？记住：每个
and_then都在延长错误传播链，而transform只改成功值，不碰错误分支
std::expected 和 C 风格错误码（如 -1 / NULL）互操作
不能直接把 open() 的返回值塞进 std::expected<int, std::error_code>。-1 本身不是错误，errno 才是。漏查 errno，就会把真实错误当成成功。
容易被忽略的地方：很多系统调用失败后 errno 不一定被设置（比如某些 glibc 版本下 close() 失败但 errno 保持原值），所以不能只依赖 errno 构造错误。
- 安全做法：先判断返回值是否表示失败（如
fd == -1），再用std::make_error_code(static_cast<std::errc>(errno))构造错误值 - 避免裸
int：不要用std::expected<int, int>存系统错误码，优先用std::error_code——它支持类别、比较、消息，且和std::system_category()兼容 - 第三方库返回
nullptr？检查前加断言或注释，std::expected<T*, std::string>可以，但别让nullptr同时代表“失败”和“空值”
真正难的不是写对第一个 std::expected，而是整个调用链都坚持用它——中间混一个裸 int 返回或一次忘记检查 has_value()，错误就悄无声息地漏过去了。
