noexcept修饰符承诺函数绝不会让异常逃逸，违反则直接调用std::terminate；它影响编译器优化（如vector移动优化）、异常处理开销、模板元编程及标准库实现策略，错误声明比不声明更危险。
noexcept 修饰符到底影响什么函数行为
加了 noexcept 不是“禁止抛异常”，而是向编译器和调用者承诺：这个函数**绝不会让异常逃逸出函数体**。一旦违反（比如在 noexcept 函数里调用可能抛异常的函数又没捕获），程序会直接调用 std::terminate()，不退栈、不析构、不给任何补救机会。
常见误用场景：
- 把
noexcept当成“我尽量不抛异常”，结果依赖的底层库或 STL 容器操作（如std::vector::push_back在内存不足时可能抛std::bad_alloc）悄悄打破了承诺 - 重载移动构造/移动赋值时盲目加
noexcept，但成员变量的移动操作本身不是noexcept（例如自定义类型未声明noexcept移动） - 函数内调用了未标注
noexcept的第三方函数，却没做 try/catch 包裹
移动操作加 noexcept 是为了触发 std::vector 的优化路径
std::vector 在扩容时需要重新安置元素。如果元素类型提供 noexcept 移动构造函数，vector 就能直接移动（std::move）旧内存中的对象到新内存；否则只能退化为“拷贝 + 析构”——既慢又可能因拷贝失败导致异常安全问题。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对资源管理类（如封装指针、文件句柄、socket 的类），只要移动操作只做指针交换、整数赋值等无异常操作，就应显式加上
noexcept - 用
noexcept检测工具验证：写static_assert(std::is_nothrow_move_constructible_v<myclass>);</myclass>防止误判 - 别为了“看起来快”硬加
noexcept：若移动构造中调用了new或malloc（虽罕见），它就不是无异常的
noexcept(true) 和 noexcept(false) 的区别远不止语义
noexcept 是 noexcept(true) 的简写，而 noexcept(false) 显式声明“可能抛异常”。关键差异在于：编译器对两者的调用开销处理不同。
具体影响：
- 调用
noexcept函数时，编译器可省略异常栈展开（stack unwinding）的运行时支持代码，减少二进制体积和间接分支预测压力 - 模板元编程中，
noexcept是可查询的类型属性：noexcept(func())表达式返回true或false布尔值，可用于enable_if分支选择 - 某些标准库实现（如 libstdc++）在
std::function存储可调用对象时，会根据目标函数是否noexcept选择不同内存布局策略
为什么 noexcept 声明错误比不写更危险
不写 noexcept，函数默认是 noexcept(false)，编译器按最保守方式生成代码，行为确定；但写错了（比如声明了 noexcept 却实际抛了异常），程序会在运行时立即终止，且调试器往往停在 std::terminate 调用点，而非原始异常抛出处。
排查难点：
- 异常发生在深层调用链中，而
noexcept函数只是“中转站”，堆栈信息被截断 - 启用
-fno-exceptions时，noexcept声明会被忽略，但代码逻辑仍可能隐含异常路径，造成跨编译选项的行为不一致 - Clang/GCC 默认不警告
noexcept违反，需手动开启-Wnoexcept-type（Clang）或依赖静态分析工具
真正难的从来不是加不加 noexcept，而是确认整个调用子图里所有路径都满足无异常承诺——尤其当涉及模板实例化、ADL 查找、隐式转换时，承诺边界很容易模糊。
