std::expected与异常机制深度对比：C++错误处理的性能与工程实践

1. 为什么突然想聊std::expected

最近群里又有人因为"异常到底该不该用"吵起来了，起因是有人在代码评审里用了std::expected，另一个同事说不认识这玩意，觉得不如继续抛异常。这场面其实这两年很常见——C++23正式把std::expected收进标准库之后，很多团队的代码规范里多了一条"新代码优先用expected，异常只留给真正的异常情况"。

先说清楚它是什么。std::expected在C++23里落地，它更像是对C++17那个std::optional的扩展，只不过optional只表示"有值还是没值"，而expected把这个概念推进一步：它要么存一个"预期中的正常值"，要么存一个"错误详情"。没有异常抛出、没有栈展开、没有运行时开销的惩罚，错误作为值老老实实地在类型系统里流动。

那问题来了，C++不是早就有异常机制吗？try/catch用了这么多年，RAII配栈展开也不是闹着玩的，为什么还要再搞一个错误处理方案出来？这个问题的答案恰恰涉及到异常机制本身的两个软肋：性能和"异常不适用于所有场景"这件事。

这篇文章不站队，我会把std::expected和异常机制从头到尾做一次对比，从异常的性能成本、类型安全、可组合性，到实际工程里怎么混用两者、怎么避坑，尽量讲得直白一点。适合正在为团队制定错误处理规范的开发者，也适合反复被问"expected和异常到底选谁"的面试候选人。

2. std::expected是什么

2.1 一段代码快速认识expected

看代码比看标准库文档直观得多。假设我们要从一个配置文件里读端口号，传统的错误处理写法是函数返回bool，再通过输出参数带回数值：

cpp复制bool read_port_from_config(const std::string& path, int& port);

这种写法的问题很经典：调用方很容易忘记检查返回值，port可能根本没被初始化，而且错误细节完全丢失，只知道"失败了"，不知道"为什么失败"。于是很多人退而求其次，选择抛异常：

cpp复制int read_port_from_config(const std::string& path) {
    if (!file_exists(path)) {
        throw std::runtime_error("config file not found");
    }
    // ...
    return port;
}

而std::expected的版本长这样：

cpp复制std::expected<int, std::string> read_port_from_config(const std::string& path) {
    if (!file_exists(path)) {
        return std::unexpected("config file not found: " + path);
    }
    return port;
}

调用的时候，代码可以这样写：

cpp复制auto port = read_port_from_config("app.conf");
if (!port) {
    std::cerr << "load failed: " << port.error() << std::endl;
    return;
}
start_server(*port);

它与optional最显著的区别就在这里：不满足条件时返回的unexpected可以携带一个我们自定义的错误类型。std::string只是最简单的一例，工程上完全可以用enum、错误码结构体，甚至一个带上下文信息的Error对象。这就把"没有值"升级成了"带着为什么没有值"。

2.2 expected不是新发明，它是函数式错误处理的延续

如果熟悉Rust的Result类型或者Haskell的Either类型，看std::expected会毫无障碍。它就是C++对这套"错误即值"理念的实现。标准委员会其实很早就铺路了——std::optional先用起来，让大家习惯"某个函数可能拿不到结果"的思维，再推出expected，让大家把"拿不到结果的原因"也装进类型里。

还有一个必须提的东西叫std::error_code。C++11其实就有了这个玩意，从POSIX错误码抽象出来的错误传播载体，配合std::system_error可以做到不抛异常也携带错误码。但问题在于，error_code的设计偏底层，适合系统调用、网络库这类场景，对应用层开发者来说不够直观。std::expected厉害的地方在于它的错误类型是模板参数，留给使用方极大的自由度。

这里插一句：expected在标准库里的别名和关系要理清，它和std::optional同属于工具组件，但语义不同。optional表示"可能没有"是正常的业务状态，比如查找一个不存在的键；expected表示"这事儿可能失败"且失败需要被看到、被处理或者被传播。工程上的语义差别很大，别混着用。

2.3 关键API与惯用法速览

先用最快的方式过一下必备API，方便后面展开对比时读者不至于迷路：

• 构造：正常返回时直接return value;，错误返回时return std::unexpected(error);
• 观察：has_value()判断是否有正常值，operator bool也可用，*解引用拿值，error()拿错误
• 转换：value_or(default)拿值或给默认值，transform对正常值做映射，and_then链式调用下一个返回expected的函数
• 错误分支处理：or_else在错误时执行一段逻辑

一个最常用的链式写法示例：

cpp复制std::expected<Config, std::string> load_config() {
    auto port = read_port_from_config("app.conf")
                    .and_then(validate_port_range) // 校验端口合法性，返回 std::expected<int, std::string>
                    .transform(Config::from_port);  // 把int转成Config对象
    return port;
}

这里值得展开讲讲and_then和transform的区别。transform是对"正常值"做映射，如果当前是错误就直接透传错误不执行函数；and_then是把"正常值"喂给下一个同样返回expected的函数，把两个可能失败的步骤串成一条链。如果中途任何一步出错，后面的步骤全部跳过，错误作为最终结果返回。这套组合子设计让错误传播变得极其简洁，从Fortran时代流传下来的"错误码逐层if判断"在它面前完全过时了。

3. 异常机制的底层真相：它到底贵在哪

3.1 零成本异常的谎言与真相

C++社区流传着一句话叫"零成本异常"，其实这句话的准确版本是"未抛出时零成本"。它的实现思路和Windows SEH、C++的Itanium ABI都不完全一样，但总体逻辑类似：编译器在正常执行路径上不生成任何检查和分支代码，代价是同时把一堆"怎么展开栈、怎么调用析构函数"的元数据放到程序的只读数据段里。代码没抛异常，这些元数据就是死内存，不占运行时间。

问题出在"一旦抛出"。异常抛出时的开销远不是一个跳转指令那么简单。它要做的事情包括：

• 根据当前PC值查找对应的异常处理表，找到匹配的catch块
• 展开栈，逐层调用局部对象的析构函数
• 进行一次或多轮的"匹配尝试"，有些实现还会做动态类型识别
• 复制或者移动异常对象到专门分配的异常存储区

这一整套下来，实际耗时可能是正常返回路径的几十倍甚至上百倍。这个数字在普通的业务程序里通常无所谓，但如果异常出现在一个低频但要求稳定延迟的系统里，比如游戏服务器的每帧逻辑、音视频同步的实时线程、或者交易系统的撮合循环，这几十倍的波动可能直接导致卡顿甚至超时。

我在实际项目里测过一次异常路径的耗时。在一个高频查询函数里故意触发异常，单次开销大概从0.2微秒涨到了12微秒，60倍的差距。对于每秒跑百万次的调用，这个方差根本无法容忍。另外还有一个隐蔽问题：异常处理需要额外的栈空间来保存try块的上下文信息，某些嵌入式平台的栈是按KB算的，随便一个try/catch块可能吃掉几KB。

3.2 异常是"非局部"的控制流

异常的另一个本质特性是控制流不直观。函数A调用函数B，B调用C，C调用D，D里抛了个异常——如果A、B、C都没有catch，异常会一层层往外跳，即使中间的函数完全没有参与错误处理的意愿。

这种设计在错误确实"无法就地处理、必须上抛到很远的地方"时效果极佳。但代价是代码的可读性和可控性下降。从读者的视角看，一个函数从头到尾读下来，根本不知道哪一行可能触发异常、这些异常会从哪里冒出来。IDE和编译器也无法给出行之有效的静态提示。

假设你在审查一段网络库代码，其中一个调用链有五六层：

cpp复制void handle_request(HttpRequest req) {
    auto user = user_service.find(req.user_id); // 这一步可能抛异常
    auto order = order_service.create(user);    // 这一步也可能抛异常
    auto result = payment_service.charge(order); // 还有可能
    send_response(result);
}

每一个函数都可能抛异常，而且异常的来源可能是内部更深层的数据库连接、序列化失败、网络超时。毫不夸张地说，这段代码的真实控制流是一个迷宫。对于负责维护它的人来说，唯一的办法是去读每一个被调用函数的实现，把所有潜在的抛出点列出来。异常机制的批评者们反复强调的"隐含控制流"指的就是这个。

3.3 异常与类型系统的脱节

异常还有一个很少被普通开发者注意到的问题：异常类型不在函数签名里。

在C++里，int f()和int g() noexcept(false)在类型系统里是可以相互转换的，从签名上你根本看不出f会不会抛、抛出的类型是什么。虽然C++11之前有过throw()动态异常规范，但已经在C++17被移除，因为实践中几乎没人维护它。反过来看Java，throws声明是签名的一部分，编译器强制调用方处理或继续声明，语义清晰得多。C++把这道门彻底拆了，好处是灵活性高，坏处是需要靠团队自律来维持"什么函数会抛什么异常"的文档约定，而这类约定几乎一定会腐烂。

std::expected在这方面的优势极为明显。错误类型直接作为类型参数写死在签名里，编译器帮你检查有没有遗漏的分支。漏掉检查expected的返回结果是编译告警（通常配-Werror还可以变编译错误），漏掉catch一个异常则只是运行时炸弹。

4. 两大方案的关键维度对比

4.1 性能与开销维度

性能是选择expected还是异常绕不开的第一道岔路口。直接上结论：

• 不抛异常时，两者的正常路径性能几乎无差别。expected比返回optional多了一点点bit位判断的成本，现代CPU分支预测能很好处理大概率成功的场景。
• 抛异常时，异常机制的耗时可以是正常路径的数十倍，且容易产生内存分配。而expected的错误分支就是一个普通的return，没有任何额外成本，和返回false差不多。
• 异常需要额外的运行时支持。即使不用try/catch，仅仅编译一个可能抛异常的函数，就会引入异常处理表数据，增加二进制体积和加载时间。

具体能省多少取决于平台的ABI。在Itanium C++ ABI的平台上，用于栈展开的.eh_frame段是出了名的体积大户，一个重度使用异常的项目里，光异常元数据就可能占据20%以上的ELF文件大小。对于自研小程序或改进手机游戏包体，这个体积差是可感知的。

这里收录一个我实测过的对比表格，同一段"文件不存在就报错"的逻辑，两种方案的二进制变化：

4.2 类型安全与接口自文档化

在函数签名上写明白"这个函数可能会失败"，这个能力恰好是异常机制给不了的。expected在类型层面强制了这种表达：

std::expected<Order, OrderError> submit_order(const Order& order);

读这行代码的人不需要翻文档，立刻知道调用方需要处理OrderError。每一次函数调用，如果没检查expected返回值，编译器的[[nodiscard]]属性还能给出警告。C++23标准里expected本身就带[[nodiscard]]，意味着丢弃它直接触发警告。

相比之下，异常机制相当于把错误处理的重担全部推给运行时。在写代码的时候，你怎么知道create_user这个函数会抛出类型A的异常还是类型B的异常？唯一可靠的办法是去读源码，这恰好在大型项目里是最不可持续的。

我见过一些大型C++代码库把"要不要抛异常"当成代码评审的重点讨论项，原因是新人经常漏catch。等线上出了故障，日志一查，异常从深层runtime_error一路扔到顶层框架，中间几层接口的维护者都傻眼了——他们根本不知道下游在抛什么。这种问题用expected来写，完全不会发生，错误类型在编译期就锁死了。

4.3 可组合性与代码简洁度

异常机制的一个经典痛点是"多个可能失败的操作连在一起时"的样板代码：

cpp复制bool fuse_operations() {
    auto result1 = try_load_data();
    if (!result1.ok()) {
        log_error(result1.error_message());
        return false;
    }
    auto result2 = try_validate_schema(result1.value());
    if (!result2.ok()) {
        log_error(result2.error_message());
        return false;
    }
    auto result3 = try_transform(result2.value());
    if (!result3.ok()) {
        log_error(result3.error_message());
        return false;
    }
    final = result3.value();
    return true;
}

每一层都要检查、都要提前返回、都要想办法把错误信息传递出去。如果中间某个出错路径忘记检查返回值，静默失败，bug就藏住了。异常机制能让这段代码短一点，靠的是"自动上抛"，不需要显式判断，但付出的代价是控制流不透明：

cpp复制void fuse_operations() {
    auto data = try_load_data();
    auto schema = try_validate_schema(data);
    final = try_transform(schema);
}

expected的写法既不牺牲类型安全也不牺牲可读性：

cpp复制std::expected<Final, std::string> fuse_operations() {
    return try_load_data()
        .and_then(try_validate_schema)
        .and_then(try_transform);
}

中间任何一步失败，后续步骤自动短路，最终拿到的是最前面那个错误值。对于业务上常见的"流水线式"操作，比如解析请求、验证权限、查询数据库、组装响应，这种写法能省掉大量重复的错误分支。代码量和异常版本相当，却保留了"每一步都显式可见"的优点。

还有一个细节值得提：expected的链式调用是标准的、可预测的，调试时打断点也方便。去追踪一串and_then链条，每一个中间状态都明明白白在返回值里，不需要靠catch往上看栈。

4.4 语义边界：什么算"业务失败"，什么算"异常"

工程上最难的从来不是API怎么用，而是业务语义怎么定。我在很多团队里看到的实际共识是：把"业务失败"和"系统异常"分开处理。

具体来说：

• 业务失败是预期内的分支，比如：用户不存在、余额不足、请求参数非法、库存不够。这些是流程中必然存在的情况，不应该用exception来表示。
• 系统异常是预期外的情况，比如：数据库连不上、文件IO错误、内存分配失败、第三方服务超时。这类问题往往需要快速失败、记录详细日志、甚至触发告警。

在这个分类下，expected天然适配业务失败，异常更适合表达真正的系统级异常。原因很简单：业务失败是函数正常返回的一部分，调用方必须处理；系统级异常是要让整个调用链上层的错误处理器介入的，草率地就地吞掉反而危险。

举一个典型的电商支付场景：

cpp复制// 用expected表达业务规则
std::expected<PaymentResult, PaymentError> process_payment(int user_id, double amount) {
    auto account = account_service.query(user_id);
    if (!account) return std::unexpected(PaymentError::AccountNotFound);
    if (account->balance() < amount) return std::unexpected(PaymentError::InsufficientBalance);
    auto order = order_service.create(user_id, amount);
    // ...
}

如果query方法底层遇到数据库socket断开，此时抛出异常是合理的，因为这不是用户能通过"换一个函数调用"解决的业务问题，而是基础设施出问题了。顶层catch捕获后，可以记录日志、发送告警、尝试重连。这个语义分层，很多经验不足的团队容易混着来：到处都抛异常，结果一个简单的"用户输入不合法"也走异常路径，性能被拖累不说，调试时栈上翻来翻去都是些毫无意义的信息。

4.5 兼容性与生态现状

std::expected有一个不能回避的短板：它要求C++23标准。虽然三方库如tl::expected可以在C++17/20里模拟，但一个团队要广泛使用它来做接口设计，还是得确保编译器和工具链支持C++23。

主流的GCC 12+、Clang 16+、MSVC 2019 16.10+都支持了std::expected。不过注意，GCC的早期版本在std::expected的某些constexpr场景有bug，Clang在模块下的表现也偶尔有问题。工程上如果要用，建议统一锁定到一个经过充分测试的编译器版本，别让标准库实现拖后腿。

与第三方库对接是个大问题。比如你的代码里大量使用expected，但第三方库的接口全是bool or error_code，中间就得写转换逻辑：把error_code转换成自己的错误类型，或者封装一层。相比之下，异常机制对第三方库几乎没有要求，库抛出的异常你可以直接catch，不需要关心具体类型。这意味着，在代码库边界比较多的复杂系统里，认认真真混用异常和expected，需要额外花精力做边界适配。

再考虑到早已存在的惯例，大部分存量C++代码库还是以异常或者错误码为主。对于想引入expected的团队，我建议先从内部模块边界做起，别一上来就要求所有新代码必须用expected。给一个过渡期，让团队逐渐熟悉"返回值传播错误"的写法，否则容易引发水土不服。

5. 我在实际项目里踩过的坑和总结的经验

5.1 当expected遇到第三方库的异常

第一个坑来自"由内而外"的混合。内部模块用了expected，但第三方库内部仍然抛异常，比如jsoncpp的解析、数据库驱动的连接失败。这时候你的模块边界就变得很难受：要么捕获第三方异常然后转成expected错误，这个捕获动作不能少；要么直接把异常往外抛，但这样你自己模块内部的错误处理就分裂了。

我的建议是在模块入口处统一做一次"异常转错误值"的适配。比如写一个bridge函数：

cpp复制std::expected<JsonValue, ConfigError> parse_json_config(const std::string& content) {
    try {
        Json::Value root;
        Json::CharReaderBuilder reader_builder;
        std::string errs;
        if (!Json::parseFromStream(reader_builder, content, &root, &errs)) {
            return std::unexpected(ConfigError(errs));
        }
        return JsonValue(root);
    } catch (const std::exception& e) {
        return std::unexpected(ConfigError(e.what()));
    }
}

这样做的核心逻辑是：第三方库的异常被彻底隔离在一个边界上，内层业务代码只跟expected打交道，不会出现"有的错用返回码、有的错用异常"的双轨地狱。虽然多写了几行，但模块内部的心智负担大大降低。

5.2 错误类型别用裸字符串

我第一次用expected时图省事，错误类型直接用std::string，结果被坑惨了。字符串错误有一个致命缺点：不能编程式地做分支判断。你只能在日志里打印它，事后靠读日志理解发生了什么。但如果你需要在错误分支里做恢复操作，比如"磁盘满了，清理缓存后重试"，用字符串你能做的只有比较内容，非常脆弱。

这种场景适合自定义错误码。C++17里有std::error_code，C++23里可以直接用枚举加自定义的error_condition。再或者用一个简单的Error结构体：

cpp复制struct AppError {
    enum class Code {
        NotFound,
        Timeout,
        InvalidArgument,
        PermissionDenied
    };
    Code code;
    std::string message;
    int http_status = 200;
};

把错误分类做成强类型，调用方可以做结构化匹配：

cpp复制if (ret.error().code == AppError::Code::Timeout) {
    // 专门处理超时重试逻辑
}

这比字符串比较可靠得多，也更贴近"用类型驱动正确性"的C++哲学。

5.3 不要把错误路径排查变成泥潭

std::expected虽然把错误包装成了值，但在错误信息丢失这件事上其实比异常更危险。异常抛出时有完整的调用栈（至少在大部分平台上），而expected只是把一个错误结构体返回给上层，调用栈信息天然不存在。如果你从头到尾用expected，发生错误时日志里只有错误码和短消息，问题的根因分析可能比异常困难。

我有一次排查一个线上问题，最终错误从最底层传上来时只剩一个"InvalidState"枚举值。从枚举到根因，中间隔着六层函数，每一层都只是把expected原样返回，没有叠加任何上下文。最后只能靠临时加日志，重新部署，才找到触发的原因。

对策是在边界处增强错误信息，别做一个只传不增的管道。每穿过一层业务语义边界，就往错误信息里附带一些"当时正在干什么"的上下文：

cpp复制auto result = repository.find_user(user_id);
if (!result) {
    return std::unexpected(AppError{
        AppError::Code::NotFound,
        "Failed to find user in repository, user_id=" + std::to_string(user_id)
    });
}

这样做以后，即使错误被上层层层透传，日志里依然能看到关键的上下文：是哪个用户、哪个操作、哪一步失败。

5.4 别把expected塞进每个函数里

另一个极端我见过很多次：团队把expected奉为圭臬，所有函数都返回expected，哪怕返回一个简单的int来实现计数器功能。结果就是：

cpp复制std::expected<int, NoError> add_one(int x) { return x + 1; }

这种写法毫无意义，反而把代码变得啰嗦和为赋新词强说愁。expected应该用在"失败确实可能发生，且调用方需要处理失败"的地方。对于不可能失败、或者失败时直接终止的简化场景——纯计算、内部工具函数、断言——直接返回值即可。

5.5 性能优化时，expected比异常更容易做局部优化

最后一个经验来自性能优化。当代码中有一个热点路径，错误处理本身占比很低时，expected能在编译器优化上给到更多空间。因为expected的错误路径和正常路径是普通的值返回，编译器可以把它当作一个struct来对待，配合返回值优化（RVO）直接构建在调用方的栈帧上，零拷贝、零额外分配。

反观异常，如果把错误对象作为异常抛出，会经过"复制到异常存储区、匹配catch、再从存储区取出"等步骤，即便经过优化也可能产生拷贝。更糟的是，有些复杂场景下异常会使函数无法内联，因为内联处理栈展开的情况相当麻烦。在追求极致性能的地方，这可能是压垮骆驼的最后一根稻草。

5.6 一个混合使用的架构建议

根据过往经验，我给一个实用而非教条的混合架构方案：

• 模块内部、业务状态流转：用std::expected，尤其是接口与状态机强相关的地方。
• 越界点与系统边界：比如线程入口、主循环、外部回调、RPC子服务入口，统一用try/catch捕获所有异常并转换成错误码或错误值，防止异常逃逸。
• 致命性系统故障：如内存不足、配置损坏、核心组件启动失败，直接抛异常，让顶层处理器快速失败、记录日志、拉起看板告警。
• 第三方库的异常：在适配层转成expected错误，避免双轨传播。
• 框架代码里对"不确定是否有异常"的不信任：可以使用noexcept声明，把"此处绝不应该抛异常"写进接口约束。

这套方案的好处是：日常业务开发主要面对expected，拥有类型安全和控制流可预测性；系统级异常仍然有异常机制兜底，保证紧急故障能快速暴露；性能敏感路径不会因为频繁的异常抛出而抖动。两套机制各管一块，不乱串。

6. 一个完整示例：从异常重构到expected

为了让大家更直观地看到代码层面的变化，用一个简化的用户注册流程来演示。先看异常版本：

cpp复制class UserService {
public:
    User register_user(const std::string& name, const std::string& email) {
        if (!validate_email(email)) {
            throw InvalidEmailError(email);
        }
        if (user_repo.find_by_email(email).has_value()) {
            throw EmailAlreadyExistsError(email);
        }
        User user{name, email, generate_id()};
        user_repo.save(user);
        return user;
    }
};

这里接口的问题是，调用方如果不读实现，根本不知道这个函数会抛哪些异常。重构为expected之后接口变成了：

cpp复制class UserService {
public:
    std::expected<User, RegisterError> register_user(const std::string& name, const std::string& email) {
        if (!validate_email(email)) {
            return std::unexpected(RegisterError::InvalidEmail);
        }
        if (user_repo.find_by_email(email).has_value()) {
            return std::unexpected(RegisterError::EmailAlreadyExists);
        }
        User user{name, email, generate_id()};
        user_repo.save(user);
        return user;
    }
};

调用方写起来又该怎样？假如有这样一个调用链：HTTP接口层 -> 用户服务层 -> 数据库仓库层。

cpp复制void handle_register_request(const HttpRequest& req, HttpResponse& resp) {
    auto user_result = user_service.register_user(req.param("name"), req.param("email"));
    if (!user_result) {
        switch (user_result.error()) {
        case RegisterError::InvalidEmail:
            resp.set_status(400);
            resp.set_body("invalid email");
            break;
        case RegisterError::EmailAlreadyExists:
            resp.set_status(409);
            resp.set_body("email already exists");
            break;
        }
        return;
    }
    resp.set_status(200);
    resp.set_body("user created: " + user_result->id);
}

这个版本的分支是编译器可枚举的，第三方静态分析工具也能帮助检查遗漏。如果把error类型换成带有HTTP状态码的结构体，还可以进一步简化：

cpp复制struct AppError {
    enum class Code { InvalidEmail, EmailAlreadyExists };
    Code code;
    int http_status() const {
        switch (code) {
        case Code::InvalidEmail: return 400;
        case Code::EmailAlreadyExists: return 409;
        }
        return 500;
    }
};

错误处理的一部分业务逻辑（状态码映射）被嵌入到错误类型中，接口层代码更加干净。这种用类型系统承载逻辑的写法在整个std::expected的设计哲学里占有核心地位。

7. 对C++错误处理未来的一点想法

标准委员会的意图其实很清楚：std::expected不是要消灭异常。它更像是给C++开发者提供一种更精细的、可选的错误处理方式，把"预期内的失败"从"异常"这个过于粗暴的通道里解放出来。异常保留它在系统级故障、无法局部处理时的价值；expected让大家在日常业务代码里有更可控、更类型安全的选择。

如果把C++错误处理机制的演进当作一条时间线：C语言时代的错误码 -> C++98的异常机制 -> C++11的error_code -> C++17的optional -> C++23的expected，可以看到每个阶段都像是在前一个方案的基础上打补丁，补齐上一代方案在某个维度上的欠缺。

未来还有一个方向是模式匹配。C++26或者更远的版本里，一旦模式匹配进标准，expected的错误分支处理会进一步简化为类似：

cpp复制inspect(result) {
    [](int value) => handle_success(value),
    [](AppError e) => handle_error(e)
};

虽然提案还在演进，但这意味着expected和模式匹配的组合会更像Rust的match和Result，彻底摆脱if/else。对于从没用过expected的C++程序员来说，现在开始学它一点也不早——这门语言在错误处理设计上的方向已经定了。

8. 给不同阶段读者的建议

如果你还在学习C++基础，你的重心不应该放在"用expected替换异常"上，而应该先把异常机制本身弄清楚。知道栈展开是什么、RAII为什么能配合异常做资源清理、为什么析构函数里不能抛出异常，这些都是C++最重要的底层素养。有了这个基础再去了解expected，能理解得更深一层。

如果你在公司维护一个老代码库，别急着推expected。先评估一下编译标准是否支持C++23，团队里有多少人熟悉函数式错误处理的写法，存量代码里异常的使用范围和频率是多少。渐进式地在新增模块中使用expected，比一锅端重构要大得多。

如果你在用C++做对稳定性要求极高的系统，比如高频交易、游戏服务端、嵌入式实时控制，认真考虑expected是值得的。它带来的性能确定性、错误传播的可控性，都是异常机制给不了的。同时也要正视它的问题：栈信息的缺失、错误上下文容易丢、第三方库不兼容。解决这些问题的方案通常靠的是工程纪律，而不是语言机制本身。

我再分享一个我个人的感受：从异常思维切换到expected思维，最难的不是语法，而是"接受错误是一个值、应该在类型层面可见"这个心法。一旦在代码里习惯了std::expected<T, E>出现在函数签名里，再去读那些"什么都不写、全靠运行时抛异常"的老接口，会有一种裸奔的不安全感。这种变化本身就说明，你对错误的敏感度已经上了一个台阶。