std::expected不能处理或替代异常，需手动用try/catch捕获异常并转为std::unexpected返回；它仅显式携带成功值或错误对象，不拦截异常、不触发栈展开。
std::expected 不能处理函数异常，也不能替代 try/catch。它不捕获异常，不拦截异常，也不参与栈展开——它只用来显式返回成功值或错误对象。
如果你的函数内部仍会抛异常（比如 std::stoi、std::filesystem::read_bytes 或第三方库的解析函数），直接用 std::expected 包裹调用是无效的，程序仍会崩溃或跳转到最近的 catch 块。
std::expected 怎么封装可能抛异常的函数
关键不是“绕过异常”，而是**主动把异常路径收口为错误值**，让整个调用链保持无异常。- 在函数体内用
try/catch捕获原始异常，再转成std::unexpected(E)返回 - 不要让异常穿透到
std::expected的调用方；否则你只是加了一层壳，没解决任何问题 - 错误类型
E推荐用enum class（如file_error、parse_error），而不是裸std::string或std::exception_ptr，便于后续switch和单元测试 - 若原函数已启用
exceptions()（如std::ifstream设置了exceptions(std::ios_base::failbit | std::ios_base::badbit)），先关掉：调用ifs.exceptions(0)，再手动检查状态位
为什么不能在构造 std::expected 时直接 throw
std::expected 的构造函数本身不抛异常（除极少数涉及移动构造失败的边界情况），但它**不提供任何异常捕获能力**。
- 写
return std::expected<int, std::string>{some_risky_func()};是危险的：如果some_risky_func()抛异常，std::expected来不及构造，异常直接上浮 - 正确做法是：先调用，再判断，再构造。例如：
auto res = some_risky_func(); if (res.has_value()) { return std::expected<int, std::string>{res.value()}; } else { return std::unexpected(res.error()); }或者更干脆地，在some_risky_func内部就完成异常→错误的转换
std::expected 和 std::ifstream 配合时最常踩的坑
std::ifstream 默认不抛异常，但它的状态检查容易误判：
-
is_open() == false可能对应路径不存在、权限不足、设备忙等多种系统错误，仅靠这个无法区分 -
good()为false时，需进一步查rdstate()，再结合errno（Linux/macOS）或GetLastError()（Windows）映射具体原因 - 别跳过
std::filesystem::status(p)预检：它比打开流快，且能提前区分not_found和permission_denied - 文本模式读取二进制内容可能触发
failbit（尤其 Windows CRLF 处理），务必显式指定std::ios_base::binary
真正麻烦的从来不是怎么写 std::expected，而是怎么把散落在 errno、rdstate()、异常对象、第三方错误码里的信息，统一收敛到一个可比对、可传递、不丢失上下文的 E 类型里。这一步漏了，后面所有链式调用都只是徒有其表。
