inline 函数不是“强制内联”，而是向编译器提请求
编译器是否真正把 inline 函数展开，取决于它自己的判断。即使你写了 inline，只要函数体过大、含循环或递归、或开启了 -O0（无优化），GCC/Clang 都大概率忽略它。MSVC 在 /Od 下也基本无视 inline 关键字。
实操建议：
- 只对短小（通常 ≤ 10 行）、无复杂控制流、且被高频调用的函数加
inline - 避免在类定义内隐式
inline大函数——比如把一个含std::vectorresize 和遍历的函数直接写在 class{} 里 - 用
__attribute__((always_inline))（GCC/Clang）或__forceinline（MSVC）可绕过编译器启发式判断，但会增大代码体积，慎用 - 检查是否生效：开 -O2 后看汇编输出（
g++ -S -O2），搜索函数名是否还以 call 指令出现
模板函数和 constexpr 函数默认 inline，但行为不同
模板函数（如 template<typename t> T max(T a, T b)</typename>）在每个实例化点都可能生成一份代码，天然具有 inline 效果；而 constexpr 函数在常量表达式上下文中必须能被编译期求值，编译器通常会优先尝试内联——但这不等于运行时调用也一定内联。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 把
constexpr当作性能开关：一个constexpr函数若参数非常量，运行时调用仍可能未内联 - 模板函数在头文件外定义（.cpp 中），导致 ODR 违反或链接失败——所有模板定义必须可见，这是 inline 的前提条件之一
- 混用
inline+ 模板：多余，模板本身已隐含 inline 语义
过度 inline 反而拖慢性能：cache 和体积的权衡
每次内联都会复制函数体代码。如果一个 20 行的函数被 50 处调用，内联后可能多出 1KB 机器码——这会挤占 L1 instruction cache，反而让其他热代码被踢出，最终执行更慢。
实操建议：
- 优先 inline 热路径上的小函数（如 getter、简单算术包装），而不是冷路径或日志/错误处理逻辑
- 用 perf record / VTune 观察指令缓存未命中率（
icache.misses），飙升时回头检查是否 inline 过度 - Release 构建下用
objdump -d或readelf -s查看符号大小，对比 inline 前后目标文件增长是否异常 - 静态成员函数、lambda（尤其带捕获的）默认不 inline，需显式加
inline或确保定义在头文件中
调试期 inline 行为与 Release 完全不同
Debug 构建（-O0）下，绝大多数编译器直接禁用 inline 优化，哪怕你写了 inline 或 constexpr。这时候断点打在函数内、调用栈清晰，但性能毫无参考价值。
关键点：
- 不要在 Debug 下测“为什么这个 inline 没生效”——它本就不该生效
- 想验证 inline 效果，必须用 -O2/-O3 编译，并关掉调试信息（-g0），否则 debug info 会干扰内联决策
- 某些 IDE（如 VS）调试时显示“内联函数不可设断点”，其实是编译器没生成独立函数符号，不是 bug
- assert 或 logging 宏里的函数调用，即使标记了
inline，在 NDEBUG 下也可能被整个剔除，别误以为是 inline 起效
inline。 
