std::expected 不是为替代异常设计的 result 类型，它缺乏错误类型可比较性、不可复制约束及 map/and_then 等函数式操作，且对移动语义敏感、要求默认构造、无 unwrap_or_else，仅适合简单同步系统调用封装。
别用 std::expected 做错误处理——C++23 标准里它根本不是为“替代异常”设计的，强行套用会踩一堆隐式转换、移动语义和短路逻辑的坑。
为什么 std::expected 不是 Result 类型
它被设计成“可选值 + 错误”的容器，但不强制要求错误类型可比较、不可复制，也不提供 map/and_then 这类函数式链式操作。你写 e.transform(...) 时，如果 T 是 void 或者 E 没有默认构造，编译直接报错。
-
std::expected<int std::string></int>可以，但std::expected<void myerror></void>要求MyError必须可默认构造——很多自定义错误类型偏偏禁用了 - 没有
unwrap_or_else，得手写e.has_value() ? e.value() : fallback()，重复逻辑藏在各处 -
transform和map_error返回的是新expected，但内部对T的移动语义很敏感：如果T移动后状态未定义（比如某些自定义句柄类），transform可能触发未定义行为
std::expected 真实可用的场景
它只适合“调用一次、返回一个结果或明确错误码”的同步函数封装，比如系统调用包装、配置解析、简单 IO。不适合嵌套、组合、或需要统一错误处理策略的业务逻辑层。
- 适合：
std::expected<int std::errc></int>包裹open()或read()，因为std::errc是 trivial、可比较、无状态的 - 不适合：
std::expected<user databaseerror></user>链式调用登录 → 查询 → 发送通知，中间任一环节失败都得手动展开检查 - 注意：GCC 13+ 和 Clang 17+ 才完整支持；MSVC 19.35+ 有部分 bug（比如
transform对右值引用处理异常）
常见编译错误和绕过方式
最常卡在“no matching function for call to ‘transform’”，本质是模板推导失败，不是你写错了，而是 T 或 E 不满足约束。
立即学习“C++免费学习笔记（深入）”；
- 错误信息：
error: no type named 'type' in 'struct std::invoke_result<...>'</...>→ 检查 lambda 返回类型是否严格匹配std::expected<u e></u>中的U，不能靠隐式转换（比如返回int却期望std::optional<int></int>） -
e.value()在!e.has_value()时是未定义行为，但编译器几乎不报 warning；必须先判空，或者用e.value_or(0)（前提是E可默认构造） - 想实现类似 Rust 的
?操作符？C++ 没语法支持。宏模拟风险极高（比如破坏 RAII 或跳过析构），不建议
真正难的不是怎么写 std::expected，而是判断什么时候不该用它——尤其当错误类型开始携带上下文、需要日志、要跨线程传递、或和 exception-based 库混用时，它的边界就迅速模糊了。
