std::expected 不支持多层嵌套错误自动展开，因类型爆炸、and_then契约破坏及手动错误转换导致胶水代码激增；推荐用std::variant统一错误类型并严格遵守and_then类型约束与解包安全规范。
std::expected 本身不支持多层嵌套错误的自动展开，必须显式定义统一错误类型或用 std::variant 合并，否则类型系统会立刻报错。
为什么不能直接嵌套 std::expected<:expected e1>, E2>
嵌套 expected 会导致类型爆炸：比如 std::expected<:expected std::string>, std::error_code></:expected>，调用方要连写两次 .has_value() 和两次 .value() 或 .error()，且无法用 .and_then 直接链式处理。更关键的是，.and_then 要求每个步骤返回相同错误类型 E，而嵌套结构天然破坏这一契约。
- 编译器拒绝推导嵌套类型的
and_thenlambda 参数类型 -
value()返回的是另一个std::expected，不是原始值，后续操作必须再解包 - 错误传播时需手动把
E1转成E2，胶水代码量激增
用 std::variant 作为统一错误类型最实用
当各层可能抛出不同错误（如文件 IO 错误、JSON 解析错误、业务校验错误），直接用 std::variant 定义顶层错误枚举，比强行统一为 std::error_code 或 std::string 更安全、可诊断。
- 定义
using LoadError = std::variant<:error_code parseerror validationerror>;</:error_code> - 每层函数都返回
std::expected<t loaderror></t>，失败时用std::unexpected(e)包装对应错误 - 顶层调用只需一次
if (!r) { handle_variant(r.error()); }，无需关心哪一层出问题 - 避免了
std::error_code无法携带结构化上下文（如字段名、行号）的缺陷
and_then 链式调用必须满足三个硬性条件
.and_then 看似简洁，但稍有不慎就会编译失败或运行时崩溃。它不是语法糖，而是对类型和生命周期的严格约束。
- 前一步返回的
std::expected<t e></t>，lambda 形参必须是T（非引用，除非你明确想移动） - lambda 必须返回
std::expected<u e></u>，错误类型E必须与上一步完全一致（包括 cv 限定符） - lambda 内捕获的局部变量若为引用或临时对象，执行到该步时可能已析构——这是最隐蔽的崩溃点
- 若某步只做副作用（如日志），仍需返回
std::expected<void e></void>，且构造时必须用std::unexpected(e)或std::expected<void e>{std::in_place}</void>
最容易被忽略的初始化和解包陷阱
std::expected 对象不可默认构造，且解包方式错一点就是未定义行为——这和 std::optional 的宽容完全不同。
- 声明即初始化：
auto r = parse_int("42");合法；std::expected<int std::string> r;</int>编译失败 - 禁止用
.has_value() && .value()组合判断：中间若发生线程切换或优化重排，.value()可能作用于空状态 - 推荐写法：
if (auto r = func(); r) { use(*r); } else { handle(r.error()); }—— 这是唯一原子安全的模式 - 对临时对象取地址（如
&func().value()）或绑定到非 const 引用，会触发移动后访问，结果不可预测
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
