inline只是编译器内联建议，是否执行由优化等级、函数特征等决定；定义须在头文件，c++17起天然支持odr豁免，否则需static或匿名命名空间；过度内联反而损害指令缓存性能。
inline 关键字不保证内联，编译器说了算
写 inline 只是给编译器一个建议，不是命令。现代编译器（如 GCC、Clang、MSVC）会基于函数大小、调用频率、优化等级（-O2 或 -O3）自主决定是否真正展开。加了 inline 却没被内联，很常见；没加却内联了，也不稀奇。
常见错误现象：inline 函数定义放在 .cpp 里，导致链接时报 undefined reference —— 因为内联函数必须在每个使用它的编译单元都可见，所以定义通常得放在头文件中。
- 只对短小、频繁调用的函数考虑
inline，比如 getter/setter、简单数学包装 - 避免在
inline函数里写循环、递归、try/catch、static局部变量 - 启用
-O2以上优化后，编译器自动内联的效率往往远超手标inline
函数体太长或含虚函数调用，基本不会被内联
编译器对“可内联性”有硬性过滤：如果函数体超过几十行、调用了虚函数、用了 alloca、含 switch 大分支、或返回大型对象（未启用 RVO），它大概率跳过内联。这不是 bug，是权衡——展开后代码膨胀可能拖慢指令缓存命中率。
使用场景举例：你封装了一个 Vec3::length()，里面就一行 sqrt(x*x + y*y + z*z)，适合标 inline；但 Scene::renderFrame() 再怎么标也没用。
立即学习“C++免费学习笔记（深入）”；
- 用
__attribute__((always_inline))（GCC/Clang）或__forceinline（MSVC）能强制，但会增大代码体积，且可能降低性能 - 检查是否真被内联：GCC 加
-fopt-info-vec-optimized，或看生成的汇编（g++ -S -O2）里有没有函数调用指令call - 虚函数调用无法静态绑定，所以含
obj->foo()的函数几乎不可能被内联，除非编译器做了 devirtualization（需 LTO +-flto）
头文件里定义 inline 函数，别忘了 static 或匿名命名空间防 ODR 违规
多个源文件包含同一头文件，若其中 inline 函数定义没加 static 或没在匿名命名空间里，而你又没开启 C++17 的 inline 变量/函数语义（即允许定义多次），链接时可能报 multiple definition。C++17 起 inline 函数天然支持 ODR（One Definition Rule）豁免，但老标准或某些嵌入式工具链仍按旧规则处理。
错误示例：math_utils.h 里写了 inline int square(int x) { return x * x; }，在两个 .cpp 里包含它，GCC 4.9 以前可能失败。
- C++17 及以后：放心用
inline函数定义在头文件，无需额外修饰 - C++11/14：加
static inline最稳妥（生成独立副本，不违反 ODR） - 或者把函数放进匿名命名空间：
namespace { inline int square(...) { ... } } - 别用
#pragma once或 include guard 来“解决”定义重复问题——它们管不了链接阶段
过度内联会让 L1 instruction cache 压力变大，反而变慢
CPU 的 L1 指令缓存通常只有 32–64 KiB，内联太多函数会让相同逻辑的代码在多个地方重复出现，挤占缓存空间。结果是：单次调用快了，但整体 cache miss 上升，实际吞吐下降。尤其在热路径上反复内联相似小函数（比如一堆 clamp()、lerp()），容易踩这个坑。
性能影响比想象中早出现：在游戏主循环或音频 DSP 处理中，哪怕只多内联 3–4 个 10 行函数，就可能让 cache miss rate 上升 5%+。
- 用 perf（Linux）或 VTune（Intel）看
icache-misses和instructions retired比值变化 - 优先内联真正热点中的叶子函数（无进一步调用），而非中间层
- 如果函数被多个模块高频调用，宁可让它保持“小函数 + 调用”，也别盲目内联——共享代码段更省 cache
内联不是开关，是和编译器讨价还价的过程。最常被忽略的点：你以为在优化速度，其实悄悄牺牲了缓存局部性；而编译器默认做的，常常比你手动标 inline 更合理。
