noexcept 能在特定场景下提升性能，但仅当编译器确信调用链全为noexcept且可跳过异常处理机制时才生效；它影响函数类型、重载决议和trait判断，误用会导致崩溃或编译失败。
noexcept 确实能帮助编译器优化，但只在特定场景下生效
编译器看到 noexcept，会认为该函数**绝不会抛出异常**，从而省去异常栈展开（stack unwinding）相关的运行时开销和代码生成。但这不是“加了就快”，而是取决于调用链和 ABI 约束：只有当编译器能确信某段路径上所有函数都 noexcept，且目标平台异常处理机制（如 Itanium C++ ABI 的 _Unwind_* 调用）可被完全跳过时，才可能生成更紧凑、更快的机器码。
典型受益场景包括：
- 移动构造/移动赋值函数被标准容器（如
std::vector::resize）调用时，若标记为noexcept，容器可能选择移动而非拷贝，避免降级为强异常安全保证 - 函数内联后，编译器发现调用链末端无异常出口，可能消除异常表（.eh_frame）条目，减小二进制体积
- 某些 STL 实现（如 libstdc++）对
noexcept函数做特化分支，例如std::move_if_noexcept
noexcept(true) 和 noexcept(false) 的语义差异很关键
noexcept 是类型系统的一部分 —— 它影响函数类型，进而影响重载决议、模板匹配和 std::is_nothrow_move_constructible 等 trait 判断。不写 noexcept 默认等价于 noexcept(false)，即“可能抛异常”；而 noexcept(true) 显式声明“绝不抛”。两者不可互换：
- 一个
noexcept(true)函数不能调用内部含throw或未标注noexcept的函数，否则编译失败 - 若函数声明为
noexcept但实际抛出异常，程序会直接调用std::terminate，不经过栈展开 - 模板中常用
noexcept(expr)检查表达式是否不抛，例如noexcept(std::declval().move())
常见误用：把 noexcept 当性能开关乱加
很多人以为加了 noexcept 就能提速，结果反而引入 bug 或抑制优化。真实陷阱包括：
立即学习“C++免费学习笔记（深入）”；
- 给调用了
std::string::push_back（可能因内存分配 throwstd::bad_alloc）的函数标noexcept，导致运行时崩溃 - 在虚函数中添加
noexcept，子类重写时必须保持一致，否则编译报错：invalid covariant return type或looser exception specification - 依赖
noexcept做 SFINAE 时，忘记它只是编译期断言，不改变运行时行为；若表达式里有未定义行为，noexcept(expr)可能返回true但实际运行仍崩
调试和验证 noexcept 是否真正起效
光看声明没用，得确认它被工具链识别并传导到了最终二进制。可用方法：
- 用
objdump -s -j .eh_frame a.out查看是否有对应函数的异常表条目；若无，说明编译器已移除异常支持逻辑 - 在函数体首行加
static_assert(noexcept(your_func()), "must be noexcept");，防止后续修改破坏契约 - Clang/GCC 下开启
-fsanitize=undefined，运行时若违反noexcept会报告uncaught exception并终止
最易被忽略的是：即使函数本身不抛，只要它调用的任何第三方库函数未标注 noexcept，你就无法安全地给它加 noexcept —— 这不是风格问题，是类型系统的硬约束。
