std::expected在多级调用中需用and_then链式传递错误，每层返回std::expected<T,E>，and_then遇error自动短路；transform仅用于无失败的值转换；E须可复制且非抽象类；性能上注意移动开销与错误粒度设计。
std::expected 在多级调用中如何传递错误
多级函数调用链里，只要某一层返回 std::unexpected，后续层级就不该继续执行——但默认情况下，std::expected 不会自动传播错误，你得显式检查或用 and_then / or_else 链式处理。
常见错误是写成这样：
auto res1 = parse_config(); auto res2 = load_data(res1.value()); // 崩溃：res1 可能含 error，value() 抛异常
正确做法是每层都用 and_then 衔接：
- 每个中间函数必须返回
std::expected<T, E>，不能混用optional或裸值 -
and_then只在前一个expected是std::expected::has_value()时才调用下个函数 - 一旦某步返回
std::unexpected，整个链立刻短路，后续函数不执行
and_then 与 transform 的区别在哪
and_then 和 transform 都能链式处理 std::expected，但语义完全不同：前者用于「可能失败的下一步操作」，后者只做「确定成功的值转换」。
立即学习“C++免费学习笔记（深入）”；
比如：
auto x = read_file("config.json")
.and_then([](std::string s) -> std::expected<Config, ParseError> {
return parse_json(s); // 可能失败 → 用 and_then
})
.transform([](Config c) -> Config {
return c.with_defaults(); // 总是成功 → 用 transform
});
如果误把 parse_json 放进 transform，编译会报错：因为 transform 要求 lambda 返回 T（即值类型），而 parse_json 返回的是 std::expected<Config, ParseError>。
-
and_then的 lambda 必须返回std::expected<U, E>，且E类型需与上游一致（或可隐式转换） -
transform的 lambda 返回纯值U，不引入新错误路径 - 混合使用时，
and_then必须放在transform前面，否则类型不匹配
错误类型 E 必须满足什么条件
std::expected<T, E> 中的 E 不是任意类型都能用——它必须可复制（CopyConstructible）、可析构（Destructible），且不能是数组或抽象类。最常踩的坑是用了未定义拷贝构造的错误类型。
例如这个结构体：
struct NetworkError {
int code;
std::string message;
std::unique_ptr<void> context; // ❌ 导致 std::expected 编译失败
};
修复方式只有两个：
- 去掉不可复制成员（如改用
std::shared_ptr或裸指针） - 显式定义拷贝构造和赋值（但要注意资源管理语义）
另外，不同层级的错误类型最好统一，否则 and_then 链会因 E 类型不匹配中断；若必须混用，可用 std::variant<E1, E2> 作为顶层 E，但会增加模式匹配成本。
性能开销和移动语义怎么处理
std::expected 在值存在时直接存储 T，不存在时存储 E，空间上是 max(sizeof(T), sizeof(E)) + 1 字节，基本无额外分配。但容易被忽略的是：如果 T 或 E 移动代价高（比如大对象、带锁资源），链式调用中频繁的 and_then 可能触发多次移动。
实操建议：
- 对大对象，优先用引用捕获 lambda（
[&]），避免值捕获引发不必要的拷贝 - 返回
std::expected时，确保内部值用std::move包裹（尤其当T不可复制时） - 不要在循环内反复构造/解包
std::expected，临时对象的构造/析构开销比裸指针判断高
真正复杂的点不在语法，而在错误类型的粒度设计——太粗（比如全用 std::string）丢失上下文，太细（每个函数定义专属错误类型）又导致 and_then 链难以衔接。这需要结合模块边界权衡，不是加个 std::expected 就自动解决的。
