std::expected 不支持深层嵌套异常处理，因其设计拒绝错误类型不统一、链式调用误用或类型堆叠表达调用栈；and_then 不自动扁平化，要求所有步骤错误类型严格一致，需统一为业务枚举如 ConfigError，并手动注入上下文，禁止异常穿透边界。
std::expected 本身不支持“深层嵌套异常”的优雅处理——这不是能力不足，而是设计上根本拒绝这种用法。所谓“嵌套异常”，通常是错误类型不统一、链式调用误用、或试图靠类型堆叠表达调用栈，结果反而让编译失败、解包崩溃、调试困难。
std::expected 的 and_then 为什么不能自动扁平化嵌套
当你写 and_then([](auto x) { return parse_json(x); })，而 parse_json() 返回 std::expected<json, ParseError>，结果不是 std::expected<json, ParseError>，而是 std::expected<std::expected<json, ParseError>, LoadError> —— 双层包装是标准行为，不是 bug。
-
and_then不做类型擦除，也不递归展开；它只保证“有值时调用回调”，不负责“回调返回值的结构规整” - 想链下去，必须让每一步的错误类型
E完全一致：连const ParseError&和ParseError都算不匹配 - 常见报错
no matching function for call to 'and_then'，八成是某步用了std::error_code，另一步用了std::string
错误类型必须统一，否则链直接断在编译期
不同环节的失败（文件打开失败、JSON 解析失败、字段校验失败）不是“不同层级”，而是同一业务流的不同失败点，应映射到同一个错误类型上。
- 定义一个业务专属枚举：
enum class ConfigError { FileOpenFailed, JsonParseFailed, FieldMissing }; - 所有函数签名都用它作
E：std::expected<Config, ConfigError>，而非混用std::error_code、std::string或自定义 struct - 对接 C API 时，立刻把
errno转成枚举：if (fd == -1) return std::unexpected(ConfigError::FileOpenFailed); - 若需保留原始
errno值，封装为结构体：struct IoError { int err_no; ConfigError kind; };，但所有步骤仍共用该类型
如何在失败路径中追加上下文而不丢原始语义
and_then 不记录调用位置，or_else 只接收当前错误，不会自动叠加“哪一步出的错”。上下文必须手动注入，且不能破坏错误可比性。
立即学习“C++免费学习笔记（深入）”；
- 避免字符串拼接：
std::unexpected("parse failed: " + e.error())会丢失==判定能力 - 推荐方式：
return std::unexpected(ParseError{.cause = e, .step = "validate_config"});，其中cause是原错误（如ConfigError枚举） - 若用
std::variant<ConfigError, ParseError, ValidationError>作E，访问时必须std::visit，不能假设某分支一定存在 - 日志增强建议放在
or_else里：.or_else([](auto e) { log("load_config failed at step X: {}", e); return std::unexpected(e); })
别让异常穿透 std::expected 函数边界
std::expected 不捕获异常。任何未被 try/catch 收口的抛异常，都会绕过它直接终止程序。
- 禁止写：
return std::expected<int, std::string>{ risky_func() };—— 若risky_func()抛异常，构造根本没机会执行 - 正确做法：先调用，再判断，再构造；或在
risky_func内部就完成异常→错误转换 - 对
std::stoi、nlohmann::json::parse这类可能抛异常的调用，必须包裹try/catch，再转成std::unexpected -
std::ifstream默认不抛异常，但若开启了exceptions(std::ios_base::failbit)，得先关掉，再手动查rdstate()
真正麻烦的从来不是怎么“链起来”，而是怎么让每一步的错误类型严丝合缝地对齐、怎么在不丢原始错误信息的前提下补足上下文、以及怎么确保异常永远不逃出 std::expected 边界——这些细节一旦松动，整个链就从编译期或运行期崩给你看。
