std::expected 不是异常自动转换器，需手动封装文件操作并捕获异常；必须检查流状态、注意异常捕获顺序、避免 and_then 生命周期陷阱，并统一路径编码以防止错误信息截断或乱码。
std::expected 打开文件时根本不会捕获 std::filesystem::file_error
很多人以为 std::expected 是个“异常替代品”，能自动把抛异常的函数转成返回 std::expected。不是这样。std::filesystem::open（或 std::fstream 构造）本身不返回 std::expected，也不自动包装异常——它该抛还是抛，std::expected 完全不介入。
想用它，得自己封装：主动调用、捕获异常、显式构造 std::expected。否则代码里写 auto res = std::filesystem::open(...) 会直接崩溃（如果失败）。
-
std::expected不是魔法开关，它只是一种类型，需要你手动参与错误路径的构造 - 标准库中目前（C++23）没有任何 I/O 函数原生返回
std::expected，包括std::fstream、std::filesystem::ifstream等 - 别指望编译器或运行时帮你“升级”老接口——这是纯手工活
怎么封装 std::fstream 构造为 std::expected<std::fstream, std::string>
最常用场景：打开一个文件，成功返回流对象，失败返回带上下文的错误信息。关键点在于捕获 std::ios_base::failure 和 std::filesystem::filesystem_error（如果用了路径操作），并统一转成字符串或自定义错误码。
示例封装逻辑：
立即学习“C++免费学习笔记（深入）”；
std::expected<std::fstream, std::string> open_file(const std::filesystem::path& p, std::ios_base::openmode mode = std::ios_base::in) {
try {
std::fstream f{p, mode};
if (!f.is_open()) {
return std::unexpected("failed to open: " + p.string());
}
return f;
} catch (const std::filesystem::filesystem_error& e) {
return std::unexpected(std::string{"fs error: "} + e.what());
} catch (const std::ios_base::failure& e) {
return std::unexpected(std::string{"io failure: "} + e.what());
} catch (const std::exception& e) {
return std::unexpected(std::string{"unknown error: "} + e.what());
}
}
- 必须检查
f.is_open()：即使没抛异常，底层 open() 失败也可能让流处于 failbit 状态 - 捕获顺序很重要：
std::filesystem::filesystem_error要在std::ios_base::failure前，否则会被后者吞掉（前者继承自后者） - 返回
std::string而非std::error_code更直观，但若需跨模块错误分类，建议定义枚举类作为错误类型
用 std::expected::and_then 链式读取内容时的生命周期陷阱
容易想当然地写 open_file(...).and_then([](auto& f) { return read_all(f); })，但这里 f 是临时 std::fstream 的引用——一旦 and_then 返回，这个临时对象就析构了，后续读取访问的是已关闭的流。
-
and_then的参数是值或 const 引用，但传入的std::fstream是移动构造来的，内部资源（fd）随对象销毁而释放 - 正确做法：把流和后续操作打包进同一个作用域，或改用返回
std::expected<std::string, std::string>的组合函数 - 更安全的链式写法是先移动出流，再显式处理：
if (auto f = open_file(p)) { auto content = read_all(*f); ... }
Windows 下 std::filesystem::path 编码与 std::expected 错误信息的隐式截断
在 MSVC 中，std::filesystem::path::string() 默认返回 UTF-8，但某些错误信息（比如含中文路径的拒绝访问提示）可能被 std::string 截断或乱码，导致 std::unexpected(...) 包装后日志不可读。
- 不要直接拼接
p.string()到错误消息里；优先用p.generic_string()或p.wstring()+std::wstring_convert（C++17 起已弃用，建议用std::osyncstream或第三方 UTF-8 转换） - 若错误类型用
std::string，确保所有路径/消息都经过一致的编码归一化（如全部转 UTF-8） - 更健壮的做法：错误类型用
struct file_error { std::filesystem::path path; std::error_code ec; };，避免字符串拼接
真正麻烦的从来不是怎么写 std::expected，而是怎么让错误信息在所有平台都不丢字、不崩、不误导人——尤其当路径里有 emoji 或生僻字的时候。
