std::expected<std::ifstream, std::error_code> 是 open() 失败时的轻量替代方案，要求 E 为可复制/移动类型（如 std::error_code 而非 std::string），配合禁用异常、正确处理 gcount() 和 eof()，并支持链式 and_then 错误传播。
std::expected 替换 try/catch 处理 open() 失败
直接用 std::expected 接收 std::ifstream 构造结果，比抛异常更轻量、意图更明确。C++23 里 std::expected<T, E> 要求 E 是可复制/移动的 error 类型，而 std::error_code 正好满足——别用 std::string 或自定义 struct 做错误值，否则编译不过。
常见错误现象：std::expected<std::ifstream, std::string> 编译失败，报错类似 static_assert failed: 'E must be copyable and movable'；这是因为 std::string 在某些标准库实现中不被视为 trivially copyable（尤其启用了 P0602），而 std::error_code 是标准保证的。
- 用
std::error_code作为E：它天然支持std::errc::no_such_file_or_directory等系统错误码 - 构造时显式传入
std::ios_base::failbit并禁用异常：否则ifstream构造失败仍会抛std::ios_base::failure - 不要在
std::expected里存std::ifstream&或右值引用——必须是完整对象，否则离开作用域就悬空
std::expected<std::ifstream, std::error_code> open_file(const char* path) {
std::ifstream f(path, std::ios_base::binary);
if (!f) {
return std::unexpected(std::make_error_code(
static_cast<std::errc>(errno)
));
}
return f;
}std::expected 链式读取：read() 和 eof() 的组合判断
传统写法里，read() 失败 + eof() 为真 ≠ 成功读完；但用户真正关心的是“是否完整读取了预期字节数”。用 std::expected 把长度校验逻辑收进返回值，避免层层嵌套 if (f) if (!f.eof()) if (f.gcount() == N)。
使用场景：读取固定头结构（如 PNG signature）、序列化二进制协议头。此时错误类型需区分“IO 错误”和“格式错误”，建议用 enum class parse_errc { io_error, truncated_header, bad_magic }，再通过 std::error_code{static_cast<int>(e), parse_category()} 封装。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
gcount()返回实际读取字节数，必须和read()后立刻检查，延迟到下一行就可能被后续操作覆盖 - 别依赖
f.fail()判断读取失败——它在eof()时也返回 true，但那是正常终止，不是错误 - 如果函数要返回解析后的结构体，把
T设为那个结构体，而不是std::vector<char>，否则调用方还得二次解析
与现有 error_code 惯例无缝对接
你项目里已有大量用 std::error_code& 出参的函数？不用重写。C++23 的 std::expected 支持隐式构造自 std::unexpected<E>，而 std::unexpected<std::error_code> 又能从 std::error_code 构造——所以旧函数可原样复用。
性能影响很小：std::expected 是零成本抽象，无虚函数、无堆分配；但要注意，若 T 很大（比如含 4KB 缓冲区的类），移动构造开销不可忽略，此时应改用指针包装或延迟初始化。
- 旧函数签名：
bool read_header(header& h, std::error_code& ec); - 新封装：
std::expected<header, std::error_code> read_header(const char* path) { header h; std::error_code ec; if (!::read_header(h, ec)) return std::unexpected(ec); return h; } - 兼容性陷阱：MSVC 19.37+ 才完整支持
std::expected的 CTAD（类模板参数推导），GCC 13 和 Clang 16 已支持；用老编译器会报template argument deduction failed
std::expected::and_then 处理多步 IO（open → read → validate）
and_then 不是语法糖，它让三步操作的错误传播变成扁平链式调用，且每个步骤的错误类型可不同（只要最终都转成统一的 E）。但注意：它不会自动展开嵌套的 std::expected<std::expected<T,E1>,E2>，必须手动 transform 或用 and_then 一层层解包。
容易踩的坑：在 lambda 里捕获局部 std::expected 对象并返回其 value()，导致移动后再次访问——value() 是非 const 成员函数，调用后原对象进入未指定状态。
- 每步返回的
std::expected的E类型最好一致（如全用std::error_code），否则and_then无法推导返回类型 - 验证逻辑（如 checksum 校验失败）应转成
std::unexpected，而不是 throw，否则破坏错误处理一致性 - 别在
and_then的 lambda 里做耗时操作（如磁盘 seek）——它本意是纯转换，副作用会让调试变困难
复杂点在于，std::expected 目前不支持类似 Rust 的 ? 操作符，所有错误分支仍需显式 if (auto r = f(); !r) return r.error(); 或用 and_then 组合。这看起来啰嗦，但恰恰迫使你面对每个错误路径——没人会漏掉 std::errc::interrupted 这种需要重试的错误。
