noexcept是编译期断言，throw()是已弃用的运行期检查；前者允许编译器在调用点优化栈展开逻辑，后者仅在运行时抛异常才终止且C++17起被弃用，混用会导致链接失败、ABI不兼容或ODR违反。
noexcept 是编译期断言，throw() 是已弃用的运行期检查
你写 void f() noexcept，编译器在函数调用点就敢做优化（比如省掉栈展开逻辑）；而 void f() throw() 只在运行时抛异常才触发终止——但 C++17 起它已被标记为 deprecated，连 clang 15 都会警告。实际项目里混用两者会导致链接失败或 ABI 不兼容，尤其在跨编译单元调用时。
常见错误现象：undefined reference to 'std::unexpected()' —— 这基本是链接了旧版 libstdc++ 但用了 throw()；或者头文件声明用 noexcept，实现文件却写了 throw()，导致 ODR 违反。
-
noexcept后面可以跟常量表达式，比如noexcept(sizeof(T) ，用于模板条件化 -
throw()不支持任何条件，只能写空括号，且无法推导 - 所有标准库容器的移动构造/赋值，仅当元素类型满足
noexcept才启用移动语义——这点直接影响性能
什么时候必须显式写 noexcept(true/false)
不是“想加就加”。只有两类场景值得你动手：移动操作 和 析构函数。前者影响容器扩容效率（如 std::vector::push_back 是否触发拷贝），后者关系到栈展开能否安全完成。
使用场景举例：自定义类 Buffer 实现移动构造函数，内部只交换裸指针和整数成员——这天然不抛异常，但编译器不知道，必须写 Buffer(Buffer&&) noexcept，否则 std::vector<buffer></buffer> 在 realloc 时仍会走拷贝分支。
立即学习“C++免费学习笔记（深入）”；
- 析构函数默认是
noexcept(true)，但只要你在里面调了可能抛异常的函数（比如fclose()没检查返回值），就得显式写~Buffer() noexcept(false) - 不要给普通业务函数乱加
noexcept，一旦内部调了std::string::append或new，运行时抛异常直接调std::terminate - 模板函数慎用
noexcept，除非你能保证所有实例化路径都不抛——推荐用noexcept(noexcept(expr))这种双重检查
noexcept 运算符：别在 constexpr 上栽跟头
noexcept 既是说明符，也是运算符，返回 bool 编译期常量。但它不是万能的“是否抛异常探测器”——它只看函数声明，不看函数体。
常见错误现象：写 constexpr bool can_move = noexcept(std::move(x));，结果 x 是个 std::vector，而 std::move 本身不抛，但 vector 的移动构造可能抛（比如分配器抛），这时 noexcept 运算符仍返回 true，误判。
- 正确姿势是查具体操作：比如
noexcept(T(std::declval<t>()))</t>判断移动构造是否noexcept - 在
static_assert里用它没问题，但在if constexpr分支里要小心——如果分支依赖noexcept结果，而该结果因模板参数未实例化而未被评估，可能静默失效 -
noexcept运算符对重载函数集不适用，必须明确指定函数指针或带参数类型，例如noexcept(static_cast<void>(f))</void>
和 C 链接、ABI 兼容性有关的坑
C++ 的 noexcept 会影响函数类型，进而影响函数指针赋值和虚函数重写规则。更隐蔽的是，它还可能破坏与 C 库的 ABI 兼容性。
使用场景：你封装一个 C 接口回调函数，声明为 extern "C" void cb(void*) noexcept，但 C 头文件里对应的原型没 noexcept，GCC 会报 cannot convert 'void (*)(void*) noexcept' to 'void (*)(void*)'。
- 所有
extern "C"函数都不能加noexcept，C 语言没有异常概念，加了等于改类型 - 虚函数重写时，子类声明
noexcept而父类没写，是合法的（更严格），但反过来不行——否则编译报错override of 'virtual void f()' cannot change exception specification - Windows 下 DLL 导出函数若含
noexcept，需确认客户端编译器版本一致，否则 mangled name 可能不同，导致GetProcAddress失败
真正难处理的是模板 + noexcept + 导出符号组合，这时候连 __declspec(dllexport) 都可能因为 noexcept 状态不同生成不同符号。遇到链接失败，先用 dumpbin /symbols 或 nm -C 对比两边符号名是否真一致。
