inline是编译器内联建议而非强制指令，是否生效取决于优化级别（如-O2）、函数复杂度、定义位置（须在头文件）及编译器自主决策；真正内联需看汇编或-Winline提示。
inline 函数能减少函数调用开销，但编译器不一定照做
声明 inline 只是对编译器的建议，不是强制指令。现代编译器（如 GCC、Clang、MSVC）会基于函数大小、调用频次、是否递归、是否有取地址操作等自行决定是否真正内联。哪怕你写了 inline，只要函数体稍复杂（比如含循环、switch、异常处理），编译器大概率忽略它。
- 真正起作用的是优化级别：必须开启
-O2或更高（GCC/Clang），或/O2（MSVC），否则inline几乎无效 - 定义必须在头文件中：因为内联需要在每个调用点“展开”，所以
inline函数的完整定义得出现在所有包含它的翻译单元里 - 重复定义不报错：这是
inline唯一被标准明确允许的“多定义”场景，避免链接时符号冲突
什么时候加 inline 才有意义
适合加 inline 的函数通常极小、无副作用、高频调用——比如访问器（getter/setter）、小型数值计算包装、模板辅助函数。例如：
inline int square(int x) { return x * x; }
inline bool is_even(int n) { return n % 2 == 0; }
- 不要给含
std::cout、文件 I/O、锁操作的函数加inline：开销不在调用本身，而在执行逻辑 - 模板函数默认隐式
inline：因为实例化发生在每个 TU，天然满足“可多次定义”要求，显式写inline是冗余的 - 类内定义的成员函数自动被视为
inline：哪怕没写关键字，如struct Vec { int len() const { return _n; } };
inline 不解决什么问题
inline 和性能优化不是一回事。它不保证更快，甚至可能因代码膨胀拖慢缓存命中率。常见误解包括：
- 不能绕过链接错误：如果只在 .cpp 里定义
inline函数，其他文件调用会报undefined reference - 不能用于虚函数：虚调用本质是查表，和内联机制冲突；即使标了
inline，编译器也基本不会内联（除非确定调用目标，如通过具体类型直接调用） - 不能抑制调试信息：Debug 模式下（
-O0）内联几乎全被禁用，断点打在inline函数里可能无法停住 - 取地址会阻止内联：一旦写了
&func，该函数必然生成独立符号，不能再内联
怎么确认函数真被内联了
别猜，看汇编。用 g++ -O2 -S 生成 .s 文件，搜索调用点附近是否还有 call 指令；或者用 Compiler Explorer（godbolt.org）实时对比。更直接的方式是加编译器提示：
立即学习“C++免费学习笔记（深入）”；
// GCC/Clang
__attribute__((always_inline)) inline void hot_path() { ... }
<p>// MSVC
__forceinline void hot_path() { ... }
-
always_inline/__forceinline是更强力的请求，但仍有例外：如函数含变长数组、嵌套函数（GCC 扩展）、或跨编译单元调用未见定义时，仍可能失败 - 启用
-Winline（GCC）能看到哪些inline请求被拒绝，以及原因（如 “function not inlined because it is larger than allowed”） - 注意：过度使用强制内联会导致代码体积激增，L1 instruction cache 命中率下降，实际性能反而变差
真正影响内联效果的，从来不是你写了几个 inline 关键字，而是函数体是否足够简单、编译器是否看到完整定义、以及优化开关有没有打开。很多所谓“性能瓶颈”，其实卡在内存布局或算法复杂度上，而不是函数调用那几条指令。
