noexcept 是函数类型的一部分，影响签名与调用；它承诺不抛异常，违者调用 std::terminate；用于移动操作、swap、析构函数等，需确保所有调用链均不抛异常。
noexcept 是函数声明的一部分，不是开关或装饰器
很多人以为 noexcept 像 Python 的 @decorator 或 Java 的 @Override，可以随时加、加了就“启用异常检查”——其实完全相反：noexcept 是函数类型的一部分，影响函数签名、重载解析和调用约定。它不改变函数体内是否抛异常，只承诺“我绝不会让异常逃出这个函数”。编译器信了，就会做优化（比如省掉栈展开逻辑），但一旦违反（比如函数里 throw 了），程序直接调用 std::terminate()，不给任何捕获机会。
常见错误现象：noexcept 函数里调用了可能抛异常的 STL 容器操作（如 std::vector::at()），或者忘了 noexcept 是继承不了的——基类虚函数声明了 noexcept，派生类重写时必须显式写上，否则编译报错。
- 使用场景：移动构造函数、移动赋值运算符、swap、析构函数（默认就是
noexcept） - 参数差异：支持两种形式 ——
noexcept（等价于noexcept(true)）和noexcept(expr)（expr 是常量表达式，比如noexcept(noexcept(f()))） - 性能影响：标为
noexcept的移动操作能让std::vector在扩容时优先选移动而非拷贝，避免深拷贝开销
怎么判断一个函数能不能加 noexcept
不能靠猜，也不能只看函数体有没有 throw。关键看所有被调用的函数是否都承诺不抛异常——包括你写的、STL 提供的、第三方库暴露的接口。C++17 起，标准库中大部分基础操作（如 std::swap、std::move、std::default_delete）都标了 noexcept，但仍有例外：std::vector::at() 抛 std::out_of_range，std::string::substr() 也可能抛，它们都不能出现在 noexcept 函数里。
容易踩的坑：用 operator[] 替代 at() 并不安全——虽然它不抛异常，但越界访问是未定义行为，和 noexcept 承诺无关；真正要的是“行为定义且不抛”，不是“恰好没写 throw”。
立即学习“C++免费学习笔记（深入）”；
- 实操建议：先查 cppreference 页面，看目标函数是否明确标注
noexcept（注意有些函数在 C++20 才补全） - 用
noexcept操作符检测：static_assert(noexcept(v.at(0)), "at() throws, can't use here"); - 对自定义类型，确保其成员函数（尤其是析构、移动）也标记了
noexcept，否则链式调用会断掉
noexcept 和析构函数的隐式规则
C++11 起，用户声明的析构函数默认是 noexcept(true)，哪怕你不写。这是强制的——因为栈展开过程中如果析构函数再抛异常，程序直接终止。所以你不能写 ~T() noexcept(false)（编译失败），除非用 noexcept(false) 显式覆盖，但那会引发更严重的问题。
常见错误现象：在析构函数里调用可能抛异常的清理逻辑（比如网络 close 失败、文件 flush 报错），又没用 try/catch 吞掉——结果触发 std::terminate，而且往往发生在异常传播中途，极难调试。
- 实操建议：析构函数里所有外部调用必须确保不抛，或用
try { ... } catch (...) { }吞掉异常 - 兼容性注意：C++98/03 代码迁移到 C++11+ 时，原有析构函数自动获得
noexcept属性，旧逻辑若依赖异常传播，必须重构 - 模板类中，如果析构依赖某个模板参数的析构函数，而该参数没标
noexcept，整个类析构也会变成noexcept(false)（隐式推导）
noexcept 误用导致 ABI 不兼容
函数是否 noexcept 会改变它的类型，因此也改变符号名（mangling）。同一个函数声明，加或不加 noexcept，在链接层面就是两个不同函数。这在动态库、跨编译单元调用、模板实例化时特别危险。
典型问题：头文件里声明了一个 noexcept 函数，但对应 .cpp 文件里定义时漏写了；或者头文件没写，实现文件加了——编译能过，链接时报 “undefined reference”。更隐蔽的是模板：一个 noexcept 版本的 std::swap 可能被选中，而另一个非 noexcept 版本没被实例化，导致运行时行为突变。
- 实操建议：声明和定义必须严格一致；头文件优先写全（尤其 public 接口）
- 用
auto+noexcept推导返回类型时要小心：auto f() noexcept -> int和auto f() -> int noexcept语义相同，但顺序错乱可能被忽略 - CI 中开启
-Wnoexcept-type（Clang）或类似警告，能提前发现不匹配
最麻烦的不是语法错，而是 noexcept 改变了调用路径却没报错——比如 vector 扩容时悄悄从移动切回拷贝，性能掉一截，还查不出原因。
