throw 和 catch 本身不慢，但栈展开才是开销大头；noexcept 可让编译器省略栈展开支持代码，提升性能并影响重载、模板特化及容器行为。
throw 和 catch 本身不慢，但栈展开（stack unwinding）才是开销大头
当你抛出异常，C++ 运行时必须从当前函数逐层往外找 catch 块，同时对所有已构造但尚未析构的局部对象调用析构函数——这个过程叫栈展开。它不是编译期决定的，需要运行时遍历调用栈、查表（.eh_frame 或类似机制）、执行析构逻辑。哪怕你没写析构函数，编译器也可能插入隐式调用（比如 std::vector、std::string 的析构）。
实操建议：
- 如果函数里全是 POD 类型（如
int、float、裸指针），且没用 RAII 资源管理，throw开销会小很多，但这种情况极少 - 避免在热路径（比如 inner loop、高频回调）中抛异常；宁可用返回码或
std::optional表达错误 - 注意：编译器通常无法对可能触发栈展开的代码做激进优化（例如内联后删掉无用变量），因为异常路径必须保留语义正确性
noexcept 不是“禁止抛异常”，而是向编译器承诺“不会抛”
noexcept 是函数类型的一部分，影响重载决议、模板特化，更重要的是——让编译器跳过为该函数生成栈展开支持代码。没有 noexcept 的函数，即使从不抛异常，编译器也得预留异常处理入口和清理逻辑。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 写了
void f() noexcept { throw 42; }—— 程序直接调用std::terminate()，不会进catch - 派生类重写虚函数时加了
noexcept，而基类没加 → 编译失败（违反协变规则） - 移动构造/移动赋值没标
noexcept，导致std::vector扩容时退化为拷贝而非移动（因为标准要求容器在移动元素时需强异常安全）
哪些地方加 noexcept 最值得？
不是所有函数都适合加 noexcept，关键是“能否 100% 保证不抛”。以下场景加了真有收益：
- 移动操作：
T(T&&) noexcept、T& operator=(T&&) noexcept—— 容器性能敏感点 - 析构函数（默认就是
noexcept）：显式写上更清晰，且防止被意外覆盖成可能抛异常的版本 - swap 函数：
void swap(T&, T&) noexcept—— 很多算法依赖它做无异常交换 - 字面量类型（literal type）的构造函数，若只做简单初始化（如
constexpr初始化），可加noexcept
别乱加：比如调用了 std::string::push_back() 的函数，内部可能分配内存失败（虽然 C++11 后 std::allocator::allocate 默认 noexcept，但自定义分配器不一定）——这时加 noexcept 就危险。
编译器实际优化效果取决于 ABI 和选项
不是写了 noexcept 就一定更快。关键看目标平台是否启用异常处理支持：
- gcc/clang 加
-fno-exceptions后，所有异常相关代码（包括栈展开逻辑）全删，此时noexcept失去意义（但语法仍合法） - Windows MSVC 默认用 SEH，Linux GCC 用 DWARF/.eh_frame，两者栈展开开销模型不同；
noexcept在两者下都能省掉对应 unwind 表项 - 某些嵌入式平台禁用异常，
noexcept主要起文档和接口约束作用
验证方法：用 objdump -d 看函数末尾有没有 call __cxa_begin_catch 或类似异常相关调用；或者对比加/不加 noexcept 后的二进制大小差异。
真正容易被忽略的是：noexcept 的传播性。比如一个 noexcept 函数调用了非 noexcept 函数，它自己就不再是 noexcept（除非显式处理异常）。编译器不会帮你“推断”，必须手动保证整条调用链干净。
