异常处理与性能：异常的开销分析、异常安全代码、noexcept优化、错误码 vs 异常

异常处理这个话题，在C++社区里争议一直很大。有人觉得异常是C++的精华，有人恨不得关掉它。我个人态度比较务实：异常有它的价值，但用不好确实会带来性能问题。今天咱们就把它掰开揉碎了聊清楚。

异常的开销到底有多大？

很多人一听到异常就摇头，说它慢。但到底慢在哪？我分三个层面说。

第一，正常路径没有开销。 这是很多人误解的地方。只要不抛出异常，try-catch块在编译后的代码里几乎不产生额外指令。现代编译器对异常的实现用了“零开销模型”（Zero-Cost Exception Handling），正常执行路径上没有任何性能损失。

第二，异常抛出时开销很大。 一旦抛出异常，编译器需要做栈展开（stack unwinding），查找匹配的catch块，调用析构函数释放局部对象。这个过程涉及大量元数据查找和运行时操作。我在项目中测过，抛出并捕获一个异常，耗时大约是普通函数返回的100到1000倍。

第三，代码体积会膨胀。 异常处理需要生成额外的展开表（unwind tables）和清理代码。这些数据放在只读段里，不会影响运行速度，但会让二进制文件变大。嵌入式场景下尤其要注意。

异常安全代码：三个级别的保证

写异常安全的代码，说白了就是保证“出错了也不会把数据搞坏”。C++社区把异常安全分成三个级别，我一个个说。

级别	含义	实际例子
基本保证	抛出异常后，对象处于有效但不确定的状态	vector的push_back失败，容器大小不变，但内容可能被移动过
强保证	操作要么完全成功，要么回滚到操作前的状态	使用copy-and-swap惯用法
不抛出保证	承诺函数永远不会抛出异常	用noexcept声明

我个人习惯是：对外接口尽量提供强保证，内部实现用基本保证就够了。曾经有个项目，我为了追求强保证，在赋值运算符里先拷贝再swap，结果发现拷贝构造本身就可能抛异常。嗯，那会儿调试了一下午才想明白。

noexcept优化：给编译器一个承诺

noexcept关键字告诉编译器：“我这个函数不会抛异常。” 编译器拿到这个信息后，可以做两件事。

第一，优化代码生成。 不需要生成栈展开相关的元数据，函数调用更轻量。对于频繁调用的小函数，效果很明显。

第二，影响容器行为。 比如std::vector在扩容时，如果元素的移动构造函数是noexcept的，它会用移动而非拷贝。移动操作通常比拷贝快得多。你想想看，如果你的移动构造函数没标noexcept，vector扩容时就会老老实实去拷贝，性能差距可能达到一个数量级。

// 好的做法
class MyData {
public:
    MyData(MyData&& other) noexcept 
        : ptr_(std::exchange(other.ptr_, nullptr)) {}
    
    MyData& operator=(MyData&& other) noexcept {
        if (this != &other) {
            delete ptr_;
            ptr_ = std::exchange(other.ptr_, nullptr);
        }
        return *this;
    }
    
private:
    int* ptr_ = nullptr;
};

错误码 vs 异常：怎么选？

这是个老生常谈的问题。我直接给结论：看场景。

什么时候用异常？

• 错误无法在本地处理，需要向上层传播
• 错误是真正的异常情况，发生频率很低
• 构造函数、运算符重载这些没法返回错误码的地方

什么时候用错误码？

• 错误是预期内的，比如文件不存在、网络超时
• 性能敏感的热路径，比如游戏引擎每帧调用的逻辑
• 嵌入式或实时系统，不允许栈展开的开销

我做过一个网络库，底层用错误码，上层业务逻辑用异常。底层IO操作频繁，用错误码避免异常开销；上层业务逻辑出错概率低，用异常简化代码。这种分层设计，既保证了性能，又保持了代码可读性。

知识体系总览

下面这张图把异常处理的核心知识点串起来了。你可以看到，异常的开销、安全级别、noexcept优化、以及错误码的选择，其实都围绕着同一个问题：如何在正确性和性能之间找到平衡。

异常处理不是非黑即白的选择。理解它的开销模型，掌握安全级别，用好noexcept，再根据场景在异常和错误码之间做取舍——这些加在一起，才是C++异常处理的正确打开方式。