std::expected性能陷阱：错误类型设计决定热路径吞吐

1. 这场Talk真正抛出的问题

CppCon 2025 的日程表出来那天，我扫到这一场时本来有点犹豫。std::expected 的使用姿势、API 设计、迁移经验，这两年社区里已经聊得很多了，再挂一个“Performance”的前缀，很容易变成“我们测了一下，性能没差多少，所以放心用吧”这种五分钟就讲完的内容。但现场坐下来之后，发现主讲人并没有走安全路线，他先用一个反向问题把所有人钩住了：

“如果在一个每秒调用数百万次的小型 RPC 解析器里，把错误码和异常改成 std::expected，错误率只有万分之一，最终吞吐反而下降了 8%，请问问题出在哪里？”

这个问题让我立刻警觉起来。因为 8% 是非常真实的性能损耗。它既不是“微秒级误差里看不出来的差距”，也不是“换成 Release 加 LTO 之后就消失”的理论损耗，而是会在关键路径上让你重新考虑整个技术选型的数字。更关键的是，它把矛头指向了一个大多数人根本没认真想过的问题：std::expected 确实是零开销的错误处理抽象，但“零开销”的前提是否成立，取决于你怎么设计错误类型、怎么写链式调用，以及你在哪一层做检查。

1.1 为什么错误处理突然变成了性能研究对象

早年 C++ 的错误处理策略其实非常两极分化：要么用异常，要么用错误码。异常在正常路径上的性能开销已经做到很低，错误路径的栈展开则非常昂贵，这使得异常特别适合“错误极少发生”的系统。错误码虽然没有异常展开的问题，但检查分散在各处，漏掉一个分支就会让错误静默传播，而且错误码一旦需要附带上下文，比如失败的那次网络请求报文、设备状态、Errno 转字符串，代码就会迅速变得臃肿。

std::expected 从设计上解决了这两个问题。它是一枚受检的“联合体”，同时为正常值和错误值准备了存放空间，代码里不能直接忽略错误，必须显式检查才能继续前进。这种机制也被称为“可恢复错误的返回类型”。但它的每次返回都意味着一份值复制或者移动，每次检查都意味着一个条件分支。这些东西在错误率达到 10% 的热循环里可以被预测器处理得不错，在错误率只有万分之一时却可能因为分支布局不当导致流水线停顿，于是“零开销”的神话就被打破了。

我并不是说 std::expected 是一个错误的选择，而是说我们这些从异常世界迁徙过来的人，需要重新建立性能直觉。异常场景下你的优化重点是“如何不让异常发生”，但 expected 场景下，你要操心的是“这个每次都构造、检查、析构的返回值，到底包含了多少个字节的无关数据”。

1.2 先说一个能让大多数人安心的短答案

为了让整篇文章后面的讨论有坐标系，我先给出这次现场听下来、加上我事后自己拉 benchmark 得到的短答案：

• std::expected<T, E> 本身没有虚函数、没有基类、没有堆分配，它的内存布局等价于一个“可以预告当前存的是 T 还是 E”的联合体；
• and_then、transform、or_else 这类 monadic operation 并不是高成本魔法，它们编译后基本就是一次 has_value() 判断加一次函数调用，很多时候只是一两条比较指令；
• 真正影响性能的，通常不是 std::expected 框架本身，而是错误类型 E 设计得太大、返回值被反复移动拷贝、检查点放置在分支预测命中率极低的位置；
• 如果你的使用姿势是“错误类型只有四五个字节，热循环里每次调用都只做一次 has_value() 检查”，那性能与裸返回加 error code 的写法的差距通常是可以忽略的。

接下来我会把这几点全部拆开讲。先看第一个最容易踩的巨坑：错误类型设计。

2. 错误的“料”比 expected 本身更能拖垮性能

在 std::expected 出现之前，我们设计错误返回时习惯把“所有可能的失败现象”都塞进错误对象里。比如文件读取失败时，你希望日志里能看到完整的错误信息、系统调用 errno、甚至文件路径。异常时代这是合理的，因为 throw 只会发生在冷路径上，错误对象再重，也不过是一次动态分配。但到了 expected 里面，这个习惯会变成灾难。

2.1 expected 的存储方式决定了 E 的大小会被平摊到每次成功返回上

std::expected<T, E> 实现方面，各家标准库虽然略有不同，但基本原则都是：用 union 同时容纳一个 T 和一个 E，再保存一个单独的标志位表明当前存的是哪个。这意味着它的大小至少是 T 和 E 两者较大者的对齐后大小，再加上一些可能的填充和状态位。

举个直观但非常常见的坏例子：从配置文件里读取一个端口号，解析成功返回 int，解析失败返回一个携带错误上下文的 std::string。

cpp复制#include <expected>
#include <string>
#include <charconv>

using ParseResult = std::expected<int, std::string>;

ParseResult parsePort(std::string_view input) {
    int value = 0;
    auto [ptr, ec] = std::from_chars(input.data(), input.data() + input.size(), value);
    if (ec == std::errc()) {
        return value;
    }
    return std::unexpected(std::string("invalid port: ") + std::string(input));
}

这段代码写起来很自然，但请你想一个问题：大多数情况下这个函数是成功的，可它每次返回的是一个会占用几十个字节的 ParseResult。std::string 本身通常就是 32 字节，再加上 int 的 4 字节、padding 和标志位，sizeof(ParseResult) 很可能是 40 甚至更多。如果一个结构体被频繁返回、复制、存储，这些多余的字节会一直在寄存器、栈和缓存之间搬运。

错误对象确实重要，但是“成功的路径不应该为错误路径的完整描述买单”这条原则，在 expected 的设计里比在异常设计里更像一把硬尺子。

2.2 把错误信息缩减成枚举或 error_code

我在自己项目里消化 Session 内容后，第一件事就是把核心解析模块的错误类型从 std::string 改成了枚举。

cpp复制enum class ParseError {
    empty_input,
    invalid_digit,
    out_of_range,
};

struct ParseErrorContext {
    ParseError code;
    int line;
};

如果只是轻量错误，直接让 E 等于一个枚举类型就够了。枚举类型默认是 int 的大小，expected<int, ParseError> 的大小通常只有 8 字节，也就是 sizeof(int) 再加上一个 sizeof(ParseError) 的空间，几乎可以被 CPU 放进一个寄存器里。

如果你确实需要保存携带上下文的详细错误，也应该把“具体消息”留在日志系统里，通过一个小的错误码去索引，而不是每次 return 时都构造字符串。很多团队不愿意引入全局日志表，那么退而求其次的好方案是用 std::error_code，它的标准实现是一个枚举错误码加一个指向 std::error_category 的指针，通常也只需要 8 到 16 字节。核心原则是：让 E 保持 trivially copyable，保持小体积，这会让你的 expected 也尽量保持 trivially copyable，从而避免很多底层拷贝开销。

我后来又做了一个对比验证。同样一个“解析端口号”的函数，一个返回 expected<int, ParseError>，另一个返回 expected<int, std::string>，在 1000 万次全成功调用中，后者明显更慢。原因不只是体积大，更关键的是非 trivially copyable 类型在进入函数返回路径时，编译器能做的优化空间变小了。寄存器传递数量变少，栈上拷贝变多，最后吞吐差距很容易超过一成。

2.3 也别让 T 侧堆无意义的“重货”

错误类型做得太大会拖垮性能，正常值 T 太大同样会。这一点在 C++ 社区其实早已有共识，但遇到 std::expected 时，很多人会忘记检查中间的 monadic chain。试想 expected<LargeRecord, Error> 的链式调用里，你每一步都可能把那个大对象移动一次，如果写成多个独立函数返回各自的对象，移动的次数还会叠加。

由于 std::expected 会把标志位和值放在一起，大对象会迫使这个结果对象整体超出理想的寄存器返回长度，于是函数返回值可能要经由内存传递，也就是调用者提前在栈上分配返回槽，被调函数写进去。多一步内存交互，正常路径的延迟就往上跳一截。这不是 expected 的问题，而是你的成功载荷已经重到不适合用返回值来搬运。实际工程里，这种大对象应该考虑用 shared_ptr 或 unique_ptr 包一层再放进 expected，或者让 T 也成为一个小型句柄类型。

现场有人把这一类问题总结得很形象：std::expected 就像你每天上下班带的通勤包，如果你把露营帐篷也一直塞在里面，又凭什么要求它轻便？

3. monadic operations 开销来源：不是判断，而是包装与移动

讲完错误类型，终于可以正面聊 monadic operations 的性能了。很多人看到 and_then 和 transform，第一反应是“这里肯定藏了一层昂贵的某种函数式抽象”。实际上理解它们之后，你会知道内部逻辑就一句话：检查当前是否持有值，持有值就调用传入的函数，不持有就直接把错误原封不动地继续往下传。

3.1 复习一下 and_then / transform / or_else 的语义

三个核心成员函数的功能如下：

• transform：如果当前持有 T，对 T 执行映射函数，得到新的 U，返回 expected<U, E>；如果当前持有 E，原样传播错误。
• and_then：如果当前持有 T，把 T 传给一个返回 expected<U, E> 的函数，并把该函数结果作为返回值；如果当前持有 E，原样传播错误。
• or_else：如果当前持有 E，对 E 执行处理函数；如果持有 T，原样返回 T。

它们不同组合起来，就能把一连串可能失败的操作串成一条管线，错误发生时自动跳过后续所有步骤。

cpp复制using Tag = std::string;
using Port = int;

struct Config {
    Tag tag;
    Port port;
};

enum class ConfigError {
    missing_tag,
    bad_port,
    file_error,
};

using ConfigResult = std::expected<Config, ConfigError>;

ConfigResult loadConfig(std::string_view path);
ConfigResult validateTag(Tag tag);
ConfigResult validatePort(Port port);

ConfigResult loadAndValidate(std::string_view path) {
    return loadConfig(path)
        .and_then([](Config cfg) {
            return validateTag(cfg.tag);
        })
        .and_then([](Config cfg) {
            return validatePort(cfg.port);
        });
}

注意上面这个例子为了方便只展示了 Control 流，但这里隐藏了一个问题：每个 lambda 都按值拿到了 cfg，如果 Config 特别大，每一步都会产生一次额外的整体复制。虽然理论上可以通过 ref-qualified 重载把移动语义利用起来，但 lambda 捕获的默认行为以及函数签名内部按值传递，很容易让对象被复制多次。这就是我说“包装与移动”是 monadic operation 主要开销来源的原因。

3.2 编译之后到底剩什么

为了验证 monadic operations 的底层成本，我在本机用 -O2 编译了一个最小函数，并故意用一个非常简单的 expected<int, int>，不断执行 and_then 链。

cpp复制using Ret = std::expected<int, int>;

Ret step1(int v)  { return v + 1; }
Ret step2(int v)  { return v * 2; }
Ret step3(int v)  { return v - 3; }

Ret chain(int input) {
    return Ret{input}
        .and_then(step1)
        .and_then(step2)
        .and_then(step3);
}

最后编译器给出的汇编里，理想情况下并没有出现一张巨大的调用表，也没有栈展开登记信息，就是一连串的 test、jne/je 和普通算术指令。各个 step 的函数只要足够小且能被内联，整个 chain 就被直接拍平成人眼可见的普通分支代码。换句话说，and_then 的抽象在编译器的热路径里通常是可以被消除的。

但这有一个前提：E 和 T 都是小型可平凡复制类型。如果你的类型在链上每一次都要拷贝一遍 500 字节的记录，那么任何编译器都救不了你，因为拷贝代码本身就是真实存在的指令，即便能内联也要全部执行。所以我很坚持的一点是，用 monadic operation 之前先把你的数据类型瘦身。

3.3 transform 与手写 if 的对比实验

我曾经收到过一种说法：“transform 里的回调是 std::function，所以有虚拟调用开销”。这里需要澄清一下。标准库里的 transform 和 and_then 都是模板，回调类型是模板参数，编译期就确定了。你传入 lambda，不会触发 std::function 的类型擦除。除非你自己在调用点显式包了一层 std::function，否则不存在虚函数调用。

我这里做个直观对比。假设函数可能失败，失败返回枚举错误。手写版本是这样的：

cpp复制std::expected<double, Error> computeManual(double x) {
    auto a = maybeSqrt(x);
    if (!a) {
        return std::unexpected(a.error());
    }
    auto b = maybeLog(a.value());
    if (!b) {
        return std::unexpected(b.error());
    }
    return b.value() * 2.0;
}

monadic 版本则是：

cpp复制std::expected<double, Error> computeChain(double x) {
    return maybeSqrt(x)
        .and_then(maybeLog)
        .transform([](double v) { return v * 2.0; });
}

在我的简单测试环境里，两个版本的汇编几乎相同，执行时间差在误差范围内。这不是什么魔法，因为两个版本的语义本来就是一致的，编译器在足够内联时得到的中间表示也高度相似。

3.4 但链太长时会产生组合式代码膨胀

别急着欢呼。实际业务代码里的 monadic chain 不像上面的三步这么短。当你有十个步骤，每个步骤内部又牵扯多个类型转换时，编译器不一定能把整条链都内联压平。最常见的问题是每个步骤返回的 expected 拥有不同的错误类型，每个 and_then 调用都需要把错误类型从 A 转换成 B。如果每个步骤都有复杂的错误转换逻辑，生成的代码就会明显膨胀，最终的指令缓存压力也随之增大。

Session 现场也提到了这个点：与其把十个短小的 and_then 串在一起，不如在某些边界上先把结果拉出来，用传统的 if 进行一次集中式判断。这个说法并不是反对链式风格，而是提醒我们，编译器不是万能的，它只是尽量在你给的约束里做出决策。当你让链条短一点、每个函数职责大一点时，分支预测和指令缓存都会更友好。这也是我使用 std::expected 写业务逻辑时的一个重要心得：链式风格用于“把错误路径统一推迟处理”非常漂亮，但不要为了链式而链式。

4. 实测：在真实热循环里把裸分支改成链式

理论讨论再多，不如实际操作一次。回到开头那个 RPC 解析器场景。我在会后花了小半天写了一个极简的模拟 benchmark：解析一行逗号分隔的消息，包含操作码、长度、时间戳，返回 expected<Message, ProtocolError>。然后我把整个解析流程写成三种形态：

1. 传统错误码：每步判断错误并提前 return；
2. 单次异常捕获：所有逻辑在一个 try 块里，失败 throw 一个自设异常；
3. expected 链式：用 and_then / transform 完成解析。

测试环境是我自己的笔记本，Release 开启 LTO，1000 万次循环。这个实验的重点不是精确测出几纳秒，而是看三种模式在相同输入下的相对差距。

4.1 第一轮：完全成功的输入

当所有输入都合法时，异常版本因为从不抛错，正常路径几乎等于没有异常机制。expected 链式版本的开销主要是每级函数对 has_value() 的判断。结果出来后，三者差距都在几个百分点以内，符合预期。std::expected 的 monadic 操作在这种场景下不会成为主要瓶颈。

4.2 第二轮：错误率为 5% 的输入

接下来往输入流里混入大约 5% 的非法报文。异常版本开始显形，所有非法报文都会走一遍 throw 和 catch，栈展开成本被放大，吞吐明显下降。传统错误码与 expected 链式则没有太大变化。这一轮验证了一个常识：频繁失败场景下，异常是最坏选择，std::expected 的受检返回天然更适合高错误率。

这里有一个数据对比很有趣：错误码版和 expected 链式版虽然总体耗时接近，但分支预测器的行为不一样。5% 的错误率对现代分支预测器来说仍然偏向“成功”，因此每次检查的错误分支大概率都能被正确预测。也就是说，额外的 has_value() 判断消耗不了太多流水线周期。

4.3 第三轮：错误率极低，但错误对象很大

第二轮用的 ProtocolError 是枚举，只有 4 字节。第三轮我故意把错误对象改成了带上下文的结构体：

cpp复制struct RichError {
    ProtocolError code;
    int line;
    uint64_t offset;
    std::string raw_message;
};

结果这次 expected 版本出现了肉眼可见的退化，且不只是失败那 5% 的调用受影响。因为整个返回值变大，每一个成功返回都要携带更大的返回对象，栈写回、寄存器搬移都增加了开支。

这组实验让我确认了 Session 的核心结论：std::expected 的性能特性是“由成功值 T 和错误值 E 共同决定的”，而不是由错误处理机制本身决定的。把 E 设计成“穷尽一切细节”的胖对象，就是给每次成功返回都附加了一笔隐藏税。

4.4 实验的启发

从那以后，我在设计库接口时给自己定了一条纪律：错误类型 E 的首要目标是“足以表达错误类别和恢复所需的上下文”，次要目标才是“方便打日志”。完整日志所需的文本信息尽量在捕获点生成，通过外置的日志链路传递，而不是塞进错误对象本身。这样设计不仅性能更好，还让错误的比较、聚合、测试变得更容易，因为枚举或 error_code 天然支持 == 和 std::hash，字符串类型则很难做高效比较。

这一点对今天大量 C++ 服务端项目的价值尤其明显。服务端往往会在调用边界做 metric 聚合，比如 Prometheus 计数器、错误日志采样。如果错误类型是有结构的枚举或 error_code，那么聚合计数可以直接 switch 分类，不会产生不必要的开销。如果错误类型是字符串，则每次聚合都要做字符串哈希和比较，热路径上的成本会进一步放大。

5. 那些藏在分支预测、内联和 error() 里的隐形成本

std::expected 的性能并不只取决于值的大小。有些隐形成本隐藏在分支布局、内联决策和 API 选择里。这些坑往往不会在微型 benchmark 里出现，但会在真实负载下变得明显。

5.1 has_value() 的检查点摆在哪里

expected 的每个检查本质上是一个布尔分支。若错误发生的位置非常集中，比如所有调用都在同一个函数里解析报头，那检查点对分支预测器来说非常友好。但如果一次成功调用要经过十个独立的检查点，每个检查点分布在不同函数里，而每个函数的失败率又不同，预测器就必须做更多工作。

最简单的优化思路是把检查尽量聚合。链式 monadic operation 的好处就是它天然把很多检查隐藏在 .and_then() 内部，代码里看着清爽，但如果你能保证某个阶段绝对不可能出错，不妨提前用 value() 把它拿出来，减少链的长度。比如解析一个已经验证过格式的内部字段时，直接使用 *iter 而不是每次都构建一个新的 expected。这样看起来少了些“函数式感”，但那一段代码才是真正的热区，牺牲一点点表达换取吞吐是值得的。

5.2 [[likely]] / [[unlikely]] 应该加在哪里

很多人在写 expected 检查时没有使用分支提示属性。如果你在循环里检查同一个结果，且你知道失败率几乎为零，就可以用 [[unlikely]] 提示编译器把错误处理分支放到远离热路径的位置：

cpp复制std::expected<Message, ProtocolError> msg = parse(raw);

if (msg.has_value()) [[likely]] {
    process(msg.value());
} else [[unlikely]] {
    handleProtocolError(msg.error());
}

这样编译器会给 process 分配更紧凑的代码路径，错误处理代码被挪出去，指令缓存更干净。实测下来，在错误率极低但每次循环都检查的热函数里，加上 [[likely]] 后确实能观察到几纳秒级别的改善。这个改善看似小，但对于每秒钟执行几百万次检查的 RPC 解析器，累积起来不可忽略。

同理，在 monadic chain 中如果某个 transform 绝大多数时候会成功，同样可以在其函数内部使用 if (condition) [[likely]]。它不是万灵丹，但如果你的 profile 能证明某条分支确实出现频率很低，加分支提示是成本最低的调优手段。

5.3 使用 value() 还是 operator* 的决定

std::expected 的 value() 在无值时会抛出 bad_expected_access，这个检查本身也是有成本的。如果你已经通过 if (result.has_value()) 确认过值存在，那么在访问阶段就不需要再次安全校验，使用 operator* 或者 operator-> 更合适：

cpp复制if (result.has_value()) [[likely]] {
    // 推荐：不再做第二次安全校验
    use(*result);
    // 不推荐：value() 内部还会再检查一次状态并可能触发异常机制
    use(result.value());
}

value() 非常方便，用于“我这里理论上不可能无值，如果万一无值就抛出异常终止”的场景很合适。但在热路径里，不要在一个已经判断过 has_value() 的分支里再调用 value()，这会导致检查点重复。

5.4 开启跨编译单元内联很重要

std::expected 的性能极其依赖编译器能否看到并内联完整逻辑。如果 T 和 E 都是公开头文件里完整定义的轻量类型，编译器能很快把整个 chain 压平。但如果把中间步骤放进一个没有 LTO 的静态库里，编译器只能看到黑盒函数签名，那么每个 and_then 都会退化成一次真正的调用加状态判断，链条越长，虚耗越大。

实践中，我在构建使用 heavy monadic pipeline 的模块时，会刻意保证这些模块开启 LTO，至少也要让编译单元内定义足够的函数体。否则你很容易得出“expected 链式写法慢得离谱”的错误结论。实际上慢的是你的构建配置，不是 std::expected。

6. 几个我整理出的实战使用原则

看完上面这些拆解，你可能会觉得 std::expected 的优化规则非常多。其实总结下来就几条，我用下来很顺手，也一并分享出来。

6.1 错误 E 尽量保持小于等于一个字

能用枚举就不用类，能用 error_code 就不用字符串，能用 const char* 静态字符串就不用分配内存的 std::string。这个原则最能立竿见影，它决定整个 expected 返回值能不能通过寄存器高效返回。只要 E 保持在 8 字节以内，expected<T, E> 的表现通常接近于一个简单结构体。

6.2 不要把“完整错误上下文”放进错误值

真正需要详细追踪错误时，正常的做法是记录错误路径中产生的所有次要信息，在最终 catch 点统一生成日志。让 E 只承载错误码和最小恢复线索。减少 E 的体积不仅是性能问题，也是系统设计问题：错误对象越轻，越容易比较、聚合、测试，越不会在错误处理代码里层层包裹。

6.3 热路径不要迷信长链

monadic chain 读起来太符合直觉了，可一旦它超过十分明显的界限，比如 5 个以上连续的 and_then 或 transform，就要考虑在中间拉出来做一次传统判断。不是函数式抽象不好，而是代码膨胀与分支预测复杂性会逐步蚕食收益。在热区里用 if 把管道切成两半，错误检查点更少，内联成功的概率更高。

6.4 不要忘了 std::expected 是为了降低错误路径成本而存在的

expected 最理想的使用场景，是高错误率下仍然保持可预测延迟，或者你需要禁止异常才能满足编译环境要求。如果你的错误率真的低到十万分之一，且代码运行环境完全允许异常，那么继续用异常可能也是个合理选项。这里没有非黑即白的答案，需要结合团队规范和实际 profile 数据做决定。

6.5 使用前确认没有让异常机制残留

如果项目原本开启 -fexceptions，但你的库选择用 expected 表达错误，请确保你没在同一路径上混合使用“抛出 std::runtime_error 的内部错误”。语言层面允许这种混合，但运行成本会退回异常模式，所有优化目的都白费了。要表达一个严重到无法恢复的错误，直接用 std::terminate 或返回一个专门的 fatal 错误码，都比在热循环里依赖异常干净。

我自己的习惯是：在库内部完全禁用异常，统一返回 expected，让上层调用方决定如何处理错误。库边界不用异常之后，二进制体积也有所下降，因为不再需要为每个可能抛错的位置生成栈展开信息。这一点在移动端或者嵌入式环境的约束下特别明显。

还有一个小技巧值得单独提一下：当你用 std::expected 作为异步任务的返回值时，注意整个对象的生命周期要尽量短。不要在容器里长期保存包含大量错误字段的 expected，因为它的体积已经包含了最大错误对象可能占用的所有空间。如果一个集合存储十万个 expected<double, std::string>，即使其中没有任何错误，每个元素也都要背着 std::string 的体积。如果改成 expected<double, std::error_code>，同样十万个元素就能节省大量内存，缓存命中率也会好很多。

这些经验里，很多都是异常时代根本不需要考虑的问题。因为异常对象只在抛出时创建，而 expected 对象在每次返回时都存在。理解这一差别，你就抓住了所有优化方向的根源：让正确路径上的代表值尽量轻，让每条链都尽量短，让编译器有机会把判断变成几条指令，让分支提示帮助 CPU 走对路。

如果整个 Session 只能浓缩成一句话，我会说：从异常迁移到 std::expected，并不是把 throw 改成 return 就结束了，它把“错误类型设计”这一项从前台直接搬进了热路径的引擎盖下。对这类代码做性能优化时，别再只盯着 and_then 和 transform 的名字看，回头检查你错误类型的大小，调整你那几条链上的检查点，收益往往比任何微优化都来得更直接。