std::expected不能直接替代try-catch，但能减少异常侵入性；适合预期失败的操作，系统级故障仍需try/catch兜底；需手动封装filesystem函数并谨慎处理错误码与权限检查。
std::expected在文件IO链路中能替代try-catch吗
不能直接替代，但能显著减少异常路径的侵入性。std::expected适合表达“预期会失败”的操作（比如std::filesystem::exists、std::filesystem::read_symlink），而std::filesystem::create_directories这类可能因权限/磁盘满等不可恢复原因抛异常的操作，仍需try/catch兜底。
关键判断：如果错误是业务逻辑的一部分（例如“配置文件不存在，用默认值”），用std::expected；如果是系统级故障（例如std::filesystem::copy中途被信号中断），它大概率仍会抛std::filesystem::filesystem_error，必须捕获。
如何把std::filesystem函数包装成返回std::expected
多数std::filesystem函数不直接返回std::expected，需手动封装。核心是捕获std::filesystem::filesystem_error并转为std::unexpected，同时处理std::errc可映射的错误码（如std::errc::no_such_file_or_directory）。
实操建议：
- 不要只捕获
std::filesystem::filesystem_error——有些函数（如std::filesystem::status）在无权限时可能返回file_status(file_type::none)而不抛异常，需额外检查status.type() == file_type::none并结合status.permissions() == perms::unknown推断失败 - 避免重复调用：像
exists(p)+is_regular_file(p)这种链式判断，应合并为一次status(p)，再用status.type()和status.permissions()综合判断，否则可能遭遇TOCTOU竞态 - 封装示例（简化版）：
std::expected<:uintmax_t std::errc> file_size(const std::filesystem::path& p) {
try {
return std::filesystem::file_size(p);
} catch (const std::filesystem::filesystem_error& e) {
if (e.code().category() == std::generic_category()) {
return std::unexpected(e.code().value());
}
return std::unexpected(std::errc::io_error);
}
}</:uintmax_t>
级联错误传播时怎么避免层层unwrap
直接调用.value()或.has_value()会打断链式流程，正确做法是用C++23的std::expected::and_then（或C++17起的手动if (auto r = f(); r.has_value()) { ... }）。
常见错误现象：写成auto size = file_size(p).value(); auto content = read_file(p);——一旦file_size失败，.value()抛std::bad_expected_access，破坏了错误语义。
推荐写法（C++23）：
- 用
and_then传递成功值：file_size(p).and_then([&](std::uintmax_t sz) { return sz > 1024 ? read_file(p) : std::expected<:string std::errc>(std::unexpected(std::errc::value_too_large)); });</:string> - 对多个IO步骤，优先用
std::expected的隐式转换（如std::expected<t e></t>可被std::expected<u e></u>接受，只要T→U可转换），减少中间变量 - 注意
and_then返回类型必须严格匹配——若前一步返回std::expected<int std::errc></int>，后一步lambda必须返回std::expected<x std::errc></x>，不能混用不同error类型
std::expected与std::optional在文件IO中选哪个
std::optional只表达“有或没有”，无法携带错误原因；std::expected能区分“不存在”和“无权限访问”，这对调试和用户提示至关重要。
使用场景差异：
- 读取配置项时，
std::optional<:string></:string>够用（只关心值是否存在） - 打开日志文件时，需要知道是
std::errc::permission_denied还是std::errc::no_space_on_device，必须用std::expected<:ofstream std::errc></:ofstream> - 跨平台代码中，Windows的
std::filesystem::permissions行为与POSIX不同，std::expected的error payload能统一记录原始GetLastError()或errno，方便后续分类处理
真正容易被忽略的是：std::expected的error type必须能被复制（或移动），而std::filesystem::filesystem_error不可复制——所以务必提取e.code()或e.what()字符串，而不是存整个异常对象。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
