c++oding="utf-8" ?>
std::expected 专为可预期的业务失败设计，强制处理带上下文的错误；std::optional 仅表示值是否存在。核心判断标准是失败是否需区分、诊断和传播具体错误信息。
std::expected 不是 std::optional 的升级版，而是解决完全不同的问题：它专为「可预期的业务失败」设计，强制你面对错误——而 std::optional 只回答“有没有值”，从不告诉你“为什么没值”。
什么时候该用 std::expected 而不是 std::optional
核心判断标准：失败是否携带**可诊断、需区分、要传播**的上下文信息。
- 用户输入解析失败（如
"abc"转整数）→ 需返回"not a number"或"out of range"，不是简单“空”——用std::expected<int std::string></int> - 配置文件字段缺失 →
std::optional可表示“该字段未提供”，但无法说明是语法错误、类型错还是权限不足——此时应选std::expected<t configerror></t> - HTTP 请求返回 401 → 失败是常态，且需区分 401/403/429/503；
std::optional<response></response>丢掉了全部状态——必须用std::expected<response httpstatus></response> - 数据库主键冲突 → 错误类型是业务语义（
DuplicateKeyError），不是“查不到”——std::optional无法承载这类信息
std::expected 的错误处理链路比 std::optional 更可控
std::optional 解包靠 .value() 或 *opt，一旦为空就 std::bad_optional_access——这本质是运行时异常，和你想避免的 throw 没本质区别。
std::expected 强制你在编译期或逻辑分支中显式分叉：
-
if (res.has_value()) { use(res.value()); }—— 明确分支，无隐式崩溃 -
if (res) { use(*res); }—— 类指针语义，但前提是已确认非 error 状态 -
res.value_or(42)—— 仅当错误类型支持默认 fallback 时可用，不掩盖问题 -
res.and_then([](int x) { return parse_next(x); })—— 函数式组合，失败自动短路，无需层层if (!ok) return ...
对比：std::optional 没有 and_then 对应物（transform 不处理“空”如何传递），业务流程中每一步都要手动检查，极易漏判。
错误类型选择直接影响可维护性
用 std::string 做错误类型最方便，但上线后难调试、难分类、难本地化；用 enum class 或自定义错误类才是生产级做法。
- 推荐：定义
enum class ParseError { InvalidFormat, OutOfRange, TrailingJunk };，再用std::expected<int parseerror></int> - 进阶：继承
std::error_code，复用系统错误域，便于与std::filesystem或网络库互通 - 避坑：别混用
std::expected<t std::string></t>和std::expected<t std::error_code></t>在同一模块——类型不兼容，无法统一处理 - 注意：
std::unexpected(E{...})构造开销取决于E，若E是大对象（如含堆内存的结构），要考虑移动语义或延迟构造
编译器支持和 ABI 兼容仍是落地硬门槛
C++23 标准虽已定稿，但主流工具链尚未全量启用：
- MSVC 19.35+（VS 2022 17.5+）支持完整
std::expected，但默认不启用异常时需确认/Zc:__has_cpp_attribute等开关 - Clang 17+ 支持，但 libc++ 需 ≥ 17；GCC 13 提供实验性实现（
libstdc++中为__gnu_cxx::expected），GCC 14 才进标准命名空间 - 若项目需兼容 GCC 12 或 Android NDK r25（基于 GCC 12），目前只能用
absl::StatusOr或自行 backport，别强行 #include - 跨 DSO 边界传递
std::expected存在 ABI 风险——尤其错误类型含虚函数或非 POD 成员时，建议只在模块内部或 header-only 场景使用
真正麻烦的不是写法，而是错误类型的粒度设计：太粗（如全用 std::string）导致后期无法做自动化归因；太细（每个子场景一个 enum）又让调用方陷入 switch 洪水。这个平衡点，得在第一个真实业务异常路径里试出来。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
