std::expected 专为错误处理设计，能明确区分成功与失败原因；std::optional 仅表示值存在与否，无错误上下文。应依语义选型：业务常态用 optional，可分类失败用 expected。
别用 std::optional 承担错误语义——它不是为失败设计的，强行塞进去只会让调用方猜错因。
std::expected 和 std::optional 的根本区别在哪
核心就一条：std::optional 只回答“有没有值”，std::expected 回答“成功了没？如果没，为什么？”
常见错误现象：用 std::optional<int></int> 表示除零失败，结果调用方看到 std::nullopt，只能靠文档或注释猜是参数非法、内存不足还是磁盘满。
-
std::optional的std::nullopt是空值语义，不带任何上下文；std::expected的std::unexpected(E)是错误语义，E 必须能说明原因（如std::error_code、std::string或自定义枚举） -
std::expected要求 E 类型可复制/可移动，且不能是void（否则该用std::optional） -
std::optional支持隐式转换到bool，std::expected不支持——必须显式调用.has_value()或用结构化绑定判断
什么时候该选 std::expected 而不是 std::optional
看函数是否“本意是成功，但有明确、可分类的失败路径”。
立即学习“C++免费学习笔记（深入）”；
典型场景包括：文件读取、JSON 解析、系统调用封装、配置加载、网络响应解析。
- 用
std::optional<user></user>适合find_user_by_id(int id)—— 用户可能真不存在，这不是错误，是业务常态 - 用
std::expected<user std::error_code></user>适合load_user_from_file(const std::string& path)—— 文件打不开、格式损坏、权限拒绝，都是需区分处理的具体错误 - 如果错误类型需要携带字符串上下文（比如 “JSON parse error at line 42: unexpected token '}'”），
std::expected<t std::string></t>比std::error_code更直接
std::expected 的 and_then 链式调用怎么写才不翻车
and_then 是函数式错误传播的核心，但它只在每个环节都返回 std::expected 时才真正可靠。
常见坑：中间某步用了 std::optional 或裸值，链就断了，编译失败或逻辑静默跳过。
- 正确写法：每个函数都返回
std::expected，例如parse_json(s).and_then(validate).and_then(save_to_db) - 错误写法：把
validate写成返回bool或std::optional，and_then无法推导类型，报错类似 “no matching function for call to ‘and_then’” - 注意
and_then的参数是值捕获的 lambda，不要在里面抛异常；若 lambda 构造std::unexpected失败（比如 E 构造函数抛异常），会直接传播出去
std::expected 的兼容性与底层陷阱
它不是语法糖，是带约束的类型——编译器、标准库、甚至你的内存布局假设都可能出问题。
当前（2026 年 4 月）完整支持需：C++23 标准 + GCC 13+ / Clang 16+ / MSVC 19.35+，且需开启 -std=c++23。
- 别对
std::expected做reinterpret_cast或memcpy：内部可能含额外标志位，非标准 layout，跨平台行为未定义 - 比较两个
std::expected不能直接用==：标准未提供默认operator==，得手动展开a.has_value() == b.has_value()，再分别比value()或error() -
std::error_code看似方便，但不带消息文本——调试时只能看到 “Invalid argument”，建议搭配std::string或自定义错误类（满足三法则）
最易被忽略的一点：std::expected 不接管异常语义，但它本身不阻止你抛异常；如果你在构造 E 时抛了异常，那异常就照常往上冒——这和它的设计目标不冲突，但容易让人误以为“用了 expected 就彻底告别异常”。实际项目里，这两者经常共存：expected 处理预期错误，异常兜底不可恢复的崩溃态。
