std::expected 不支持链式调用，需用逐层检查+提前返回避免缩进地狱和未定义行为；错误类型必须可移动或可复制；可手动实现简易 and_then 辅助函数。
std::expected 不能直接链式调用多个可能失败的操作
因为 std::expected 没有内置的 and_then 或 map（C++23 标准里确实没加），你没法像 Rust 的 Result 那样自然写 a().and_then(b).and_then(c)。强行嵌套 if (auto r = f(); r.has_value()) { ... } 会迅速变成“缩进地狱”，尤其在 3 层以上分支时逻辑难读、错误处理易漏。
常见错误现象是：手动展开后忘记检查某一层的 has_value()，或误把 value() 当作安全调用——一旦 has_value() == false 就触发未定义行为。
- 必须始终先检查
has_value()或用operator->()/operator*()前确认状态 - 不要对临时
std::expected对象直接调用value()，容易因移动语义导致二次取值崩溃 - 若分支中需复用上层成功值，建议用具名变量承接，而非反复解包
用 if-else 层叠 + 提前返回是最稳妥的多重分支写法
这是目前（C++23）最清晰、最易调试、也最不容易出错的方式。核心原则：每个可能失败的步骤单独一行声明，失败立即 return 或 throw，不深套。
std::expected<int, std::string> parse_and_validate(const std::string& s) {
auto parsed = try_parse_int(s); // 返回 expected<int, err>
if (!parsed.has_value()) return parsed; // 直接透传错误
auto validated = validate_range(parsed.value()); // int → expected<int, err>
if (!validated.has_value()) return validated;
auto normalized = normalize_value(validated.value()); // int → expected<int, err>
if (!normalized.has_value()) return normalized;
return normalized; // 所有步骤成功
}
这种写法天然支持不同步骤返回不同错误类型（只要都满足 std::unexpected 可转换），且每步的错误信息能原样保留，调试时堆栈清晰。
立即学习“C++免费学习笔记（深入）”；
- 避免写
if (auto v = f(); v.has_value()) { g(v.value()); }—— 这里v是临时对象，v.value()在g中若抛异常，v可能已被析构 - 如果某步不需要上一步的值（比如只是校验副作用），可直接用
if (!f().has_value()) return ...; - 函数返回类型必须统一，否则编译失败；必要时用
std::variant包装多种错误类型
想模拟链式调用？自己封装一个 minimal and_then
标准库没提供，但你可以写一个极简版辅助函数，只处理单参数、返回 std::expected 的 callable：
template <typename T, typename E, typename F>
auto and_then(const std::expected<T, E>& e, F&& f)
-> decltype(f(std::declval<const T&>())) {
if (e.has_value()) return f(e.value());
else return std::unexpected(e.error());
}
用法示例：
auto r = and_then(try_parse_int("42"),
[](int x) { return validate_range(x); });
r = and_then(r, [](int x) { return normalize_value(x); });
注意：这个版本不支持移动语义优化（e 是 const 引用），也不处理 F 返回非 expected 的情况。真要工程级使用，得补全 SFINAE 或 concept 约束，但多数场景够用。
- 别试图重载
operator>>或|模拟 Haskell 风格——可读性反而下降，且容易和位运算混淆 - 如果
F可能抛异常，and_then不捕获，异常会穿透；这符合预期，但需确保调用方有兜底 - 返回类型推导依赖
F的返回值，务必保证所有分支路径都返回std::expected同构类型
std::expected 的错误类型必须可复制或可移动，否则编译失败
这是实际编码中最常被忽略的约束。比如你定义了一个含 non-copyable 成员（如 std::mutex）的错误类：
struct MyError {
std::mutex mtx; // ← 编译失败！
std::string msg;
};
那么 std::expected<int, MyError> 无法实例化，因为 std::expected 内部需要拷贝或移动错误值（例如在 error() 被调用时）。
- 错误类型应轻量、无资源独占语义；推荐用
std::string、enum class或std::error_code - 若必须携带上下文数据，用
std::shared_ptr包裹，而不是裸指针或 unique_ptr - 测试时用
static_assert(std::is_move_constructible_v<E>)显式检查错误类型是否合规
多重分支下，错误类型不满足要求的问题往往到第二或第三步才暴露，因为前面的 expected 实例化没问题，但组合后模板实例化深度增加，约束才浮出水面。
