std::expected 不是函数式编程银弹，需配合 move 语义、恰当构造时机和明确错误传播意图；应避免临时构造返回、慎用嵌套链式调用，区分其与 optional 和异常的适用场景。
std::expected 不是函数式编程的银弹，它只是让错误处理更像值传递——但必须配合 move 语义、恰当的构造时机和明确的错误传播意图才能用好。
std::expected 的构造和返回值怎么写才不踩坑
直接用 std::expected<T, E> 返回成功值或错误，但别在函数内临时构造再返回：编译器可能无法 elide 拷贝，尤其当 T 或 E 不可拷贝时会编译失败。优先用 std::in_place 或隐式转换构造。
- ✅ 推荐：
return std::expected<int, std::string>(42);（隐式构造成功） - ✅ 推荐：
return std::unexpected("file not found");（类型推导清晰） - ❌ 避免：
std::expected<BigObject, Err> res; res = BigObject{...}; return res;（触发不必要的移动或拷贝） - ⚠️ 注意：
std::expected的value()在 error 状态下调用会抛std::bad_expected_access，不是断言也不是返回 optional-like 的空值
链式调用时如何避免嵌套 std::expected<std::expected<...>>
std::expected 没有内置 and_then 或 map（C++23 标准里也没有），强行链式容易套娃。必须手动展开，或封装辅助函数。
- 常见错误：写
auto r1 = f(); auto r2 = r1.has_value() ? g(r1.value()) : std::unexpected(r1.error());—— 冗长且易漏 error 分支 - 实用做法：定义一个 inline helper，比如
template<typename F> auto and_then(const std::expected<T, E>& e, F&& f) -> std::expected<std::invoke_result_t<F, T>, E>，内部做has_value()判断并转发 - 别依赖第三方库的“monadic”扩展（如 tl::expected），除非团队已统一约定；标准库版本不保证 ABI 兼容，跨模块传递
std::expected时尤其要注意
和 std::optional、异常处理对比时该选哪个
std::expected 表达的是「预期可能失败，且失败原因需携带上下文」，不是 optional 的替代品，也不是异常的平替。
立即学习“C++免费学习笔记（深入）”；
-
std::optional适合“值可能存在/不存在”，无错误语义（比如缓存查找未命中）；std::expected适合“操作可能失败，且失败需诊断”（比如解析 JSON 字段缺失或类型不符） - 异常适合不可恢复、跨多层调用栈的错误（如内存耗尽）；
std::expected适合可预测、应被调用方显式处理的业务错误（如用户输入格式错误） - 混合使用没问题，但别把
std::expected<T, std::exception_ptr>当异常转接器——这既失去静态错误类型优势，又没获得栈展开能力
真正麻烦的是错误类型的粒度设计：用 enum class 还是自定义 struct？前者利于 switch 分支，后者能带字段信息；但一旦暴露给下游，改枚举就破坏二进制兼容性。这个权衡点，文档里不会写，但上线后第一周就会碰到。
