std::expected 不支持流式错误传递，因其非 monad 且无 and_then 或 map 成员函数；正确用法是尽早检查并显式返回，配合 C++23 的 std::transform 或手动短路处理。
std::expected 不能直接用于流式错误传递
它不是 monad，没有 and_then 或 map 成员函数，也不能像 Rust 的 ? 那样自动传播错误。强行“链式调用”必须手动解包、检查、提前返回，否则会丢失错误语义或触发未定义行为。
常见错误是写成这样：
auto res1 = parse_input(); auto res2 = process(res1.value()); // 崩溃：res1.has_value() == false 时调用 value()
这本质上是把 std::expected 当成可空指针用，完全没利用其错误携带能力。
手动传播错误的最小可行模式
真正实用的流式控制，靠的是「尽早检查 + 显式返回」，配合 C++23 的 std::expected::transform（注意：不是成员函数，是自由函数）或手写辅助逻辑。
立即学习“C++免费学习笔记（深入）”；
- 每个函数返回
std::expected<T, E>，绝不返回裸值或抛异常 - 调用方用
if (!res.has_value()) return res;短路，而不是res.value() - C++23 起可用
std::transform(res, [](auto&& v) { return f(v); })做单层映射，但不支持嵌套传播 - 多步串联建议封装为 lambda 或局部函数，避免深度缩进
示例：
auto step1 = read_config(); if (!step1) return step1; auto step2 = validate(step1.value()); if (!step2) return step2; return execute(step2.value());
为什么不用 operator>> 或自定义管道符
有人尝试重载 | 或 >> 模拟流式语法，比如 read() >> parse >> run。这在技术上可行，但代价很高：
- 类型擦除或模板爆炸导致编译时间激增
- 错误类型必须统一（如全用
std::string），丧失std::expected的强类型错误优势 - 调试困难：栈回溯里看不到中间步骤，错误位置模糊
- Clang/GCC 对复杂 ADL 解析不稳定，容易触发 SFINAE 失败
标准库没提供这类操作符，正说明它不被鼓励 —— std::expected 的设计哲学是「显式优于隐式」。
真正值得投入的简化手段
与其造管道，不如聚焦三件事：
- 用宏封装重复的检查模式（例如
TRY(expr)展开为auto _t = (expr); if (!_t.has_value()) return _t;），但需注意宏作用域和求值顺序 - 对固定错误类型（如
std::error_code）用std::expected<T, std::error_code>，便于与 POSIX/Win32 API 互操作 - 在顶层（如 main 或 handler）统一处理错误：
if (auto err = run_all(); !err.has_value()) log(err.error());
最易被忽略的一点：不要试图让 std::expected 承担日志、重试、降级等业务逻辑 —— 它只负责「这次调用是否成功」，其余交给上层决策。
