inline是编译器优化建议而非强制指令，是否内联由编译器依上下文决定；其核心作用是解决头文件中函数定义的ODR问题，确保多文件包含时不链接错误。
内联函数的本质是编译器的优化请求，不是强制指令
在 C++ 中，inline 关键字只是向编译器提出“建议”：这个函数适合展开为内联代码，避免函数调用开销。它不改变函数语义，也不保证一定被内联——最终是否内联由编译器根据上下文自行判断。现代编译器（如 GCC、Clang、MSVC）基本忽略 inline 的“请求”属性，转而基于自身优化策略（如 -O2 下的函数大小、调用频率、是否含循环/递归等）做决定。
编译器拒绝内联的常见场景
即使你写了 inline，编译器也常会跳过内联，典型情况包括：
- 函数体过大（例如含多层循环、大段逻辑或大量模板实例化），内联后显著增大目标代码体积
- 函数含递归调用（
inline void f() { f(); }），无法静态展开 - 函数地址被显式取用（
&func），必须保留可寻址的函数实体 - 函数含虚函数调用、异常处理（
try/catch）、可变参数（...）等难以安全展开的结构 - 跨翻译单元调用且未启用 LTO（Link-Time Optimization），编译器在单个 .cpp 里看不到定义（此时
inline主要解决 ODR 违规，而非触发内联）
inline 和函数定义位置强相关
inline 最不可替代的作用其实是解决“一个定义规则”（ODR）问题。当函数定义放在头文件中（比如模板实现、工具函数），多个 .cpp 包含该头文件时，若不加 inline，链接阶段会报 multiple definition 错误。这时 inline 告诉链接器：“这些定义是等价的，任选其一即可”。所以即使编译器没内联它，inline 仍有语义价值。
注意：C++17 引入 inline 变量，同样用于头文件中定义全局变量而不违反 ODR。
立即学习“C++免费学习笔记（深入）”；
如何验证是否真被内联了
别靠猜测，看汇编最直接：
- GCC/Clang：加
-S -O2生成 .s 文件，搜索函数名是否作为独立标签出现；若只看到指令流嵌入调用点，大概率已内联 - MSVC：用
/FA生成汇编，或调试时在反汇编窗口观察调用点是否变成指令序列 - 更稳妥方式：用
__attribute__((always_inline))（GCC/Clang）或__forceinline（MSVC）强制要求（但依然可能失败，比如含递归时编译器会报 warning C4714）
真正影响性能的，往往不是某处是否内联，而是数据局部性、分支预测、缓存行对齐等底层因素。把 inline 当作微优化手段前，先确认它确实是瓶颈所在。
