noexcept本身不开启内联，但会提升编译器内联意愿，尤其在消除异常栈展开顾虑后；典型受益函数包括移动构造/赋值、swap特化、访问器及constexpr函数。
noexcept 不是内联开关，但会影响编译器的内联决策
直接说结论：noexcept 本身不会“开启”内联优化，但它让编译器在做内联判断时，**更愿意**把函数内联——尤其当调用链中存在异常传播路径时。这是因为 noexcept 消除了异常栈展开的开销顾虑，编译器能更安全地假设：内联后不会增加异常处理的复杂度。
哪些函数加 noexcept 最容易触发内联收益
典型场景是短小、高频、且本就不该抛异常的函数，比如：
-
std::swap的特化（自定义类型的交换） - 移动构造函数和移动赋值运算符（
T::T(T&&)/T& operator=(T&&)） - 访问器函数（
size()、data()、empty()等） - 纯计算型
constexpr函数（即使没显式写noexcept，它也隐式noexcept(true)）
例如：
struct Vec {
int* ptr;
size_t sz;
Vec(Vec&& other) noexcept : ptr(other.ptr), sz(other.sz) {
other.ptr = nullptr;
other.sz = 0;
}
};这里加 noexcept 后，编译器看到移动构造不抛异常，就更可能在 std::vector<vec>::push_back(std::move(v))</vec> 这类调用中把它内联，避免一次函数调用开销 + 异常表注册成本。
立即学习“C++免费学习笔记（深入）”；
不加 noexcept 可能被编译器“拒内联”的真实原因
不是编译器“拒绝”，而是权衡后认为风险/代价过高。关键点有三个：
- 异常传播会强制生成栈展开信息（.eh_frame 或类似），即使函数体很短，这部分元数据会让内联后的调用点变重
- 如果调用链上某处是
noexcept(false)（默认），而你又在noexcept(true)函数里调用了它，编译器必须插入运行时检查（std::terminate调用点），反而降低内联收益 - 某些 ABI（如 Itanium C++ ABI）要求所有可能抛异常的函数都参与异常传播链，这限制了跨编译单元的内联（尤其是 LTO 关闭时）
所以，如果你发现一个明显该内联的小函数没被内联，用 objdump -d 或 clang -S -O2 看汇编，常能看到调用指令未被展开——这时检查它是否被标记为 noexcept，以及它的所有直接调用目标是否也都 noexcept，往往就是突破口。
实际验证：怎么确认 noexcept 帮你拿到了内联
别猜，直接看编译器输出：
- Clang：加
-Rpass=inline（或-Rpass-missed=inline对比） - GCC：加
-fopt-info-vec-optimized或更准的-fopt-info-inline-optimized - MSVC：加
/d1reportAllClassLayout配合/d1reportTime不太直观，推荐用/FA生成汇编再搜call
例如 Clang 下：
clang++ -O2 -Rpass=inline test.cpp
如果看到类似 inlined into 'foo' at test.cpp:5:12，且该函数声明含 noexcept，而删掉后这条提示消失，基本就坐实了影响。
真正容易被忽略的是：noexcept 的传播性。你给一个函数加了 noexcept，但它内部调用了某个没加 noexcept 的第三方函数，整个函数仍会被视为 noexcept(false) —— 编译器会静默降级，连警告都不给。这时候得一层层查调用链，而不是只盯最外层声明。
