std::expected适用于有明确成功值和确定错误类型的I/O或数据转换场景，且调用方不希望异常中断或使用魔法值；不适合底层系统调用、泛型错误路径或运行时不确定错误类型的情况。
std::expected 什么时候该用，什么时候不该用
它不是 std::optional 的替代品，也不是 throw 的平替。真正适合的场景是：函数明确有「成功值」和「确定错误类型」两个互斥结果，且调用方**不希望异常中断控制流**，也不愿用魔法返回值（比如 -1、nullptr）或输出参数。
常见误用：包装可能抛异常的函数（比如 std::stoi）却不处理 std::invalid_argument——这会让错误被静默吞掉；或者用 std::expected<void e></void> 当作“无返回值 + 错误”时，却忘了 void 类型无法被拷贝，必须用 std::move 传递。
- 适合：文件打开、JSON 解析、网络请求响应解析等边界清晰、错误可枚举的 I/O 或数据转换操作
- 不适合：底层系统调用封装（errno 变化多端）、模板元编程中泛型错误路径、或错误类型本身不确定（如需要运行时字符串描述）
- 注意：
std::expected对象本身不可默认构造，声明时必须初始化为std::expected<t e>{value}</t>或std::expected<t e>{std::unexpect, error}</t>
如何正确构造和检查 std::expected
别用 .has_value() + .value() 组合——一旦 .value() 在无值时调用，行为未定义（不是抛异常，是 UB）。正确方式是先用 .has_value() 判断，再用 .value() 或 .error()；或者直接用 if (auto r = func(); r) { /* success */ } else { /* r.error() */ }。
示例：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::expected<int, std::string> parse_int(const std::string& s) {
try {
return std::stoi(s);
} catch (const std::exception&) {
return std::unexpected("invalid integer format");
}
}
<p>auto r = parse_int("42");
if (r) {
std::cout << "got: " << *r; // OK: dereference works
} else {
std::cout << "error: " << r.error(); // safe
}-
*r和r.value()等价，但仅在r.has_value()为 true 时合法 -
r.error()同理，只在!r.has_value()时可用 - 不要对临时
std::expected对象取地址或绑定到非 const 引用——移动语义可能让后续访问失效
链式调用与错误传播怎么写才不崩
std::expected 没有内置 map 或 and_then（C++23 标准没提供），得自己写或借助第三方（如 tl::expected）。标准库只给了 .transform()（C++23 起），但它要求传入的 callable 返回 T 或 std::expected<U, E>，且失败时自动短路。
关键限制：.transform() 不接受返回 std::expected<U, F>（F ≠ E）的函数——错误类型必须一致，否则编译失败。想做错误类型转换，得手动解包再重建。
- 安全链式写法示例：
auto r = parse_int("123").transform([](int x) { return x * 2; }); // r 是 std::expected<int, std::string>- 错误转换需显式处理：
if (!r) return std::unexpected(std::make_error_code(std::errc::invalid_argument)); - 嵌套调用时，避免连续多个
.transform()套娃——每层都增加一层临时对象开销，且可读性骤降
和传统错误处理方式对比时的真实代价
比起 errno 或返回码，std::expected 占用更大内存（通常至少两个指针宽度），且不能零成本抽象：即使你从不使用错误分支，编译器也得为 std::unexpected 分支生成代码。但在 debug 构建下，它比异常更可控；在 release 下，若编译器能证明错误路径永不执行，优化后可能接近内联返回码。
真正容易被忽略的是 ABI 兼容性：std::expected<T, E> 的二进制布局未标准化，不同标准库实现（libstdc++ / libc++ / MSVC STL）之间不能直接传递。跨动态库边界时，要么统一 STL 实现，要么只传 POD 类型并自行序列化错误。
- 小对象（如
std::expected<int, std::errc>）通常能放进寄存器，性能影响微乎其微 - 大错误类型（如
std::string）会触发堆分配，且移动构造可能比简单整数返回慢一个数量级 - 如果项目已重度依赖
boost::system::error_code，强行切到std::expected<T, std::error_code>并不会自动获得兼容性——错误码语义仍需手动映射
