inline函数不一定被内联，编译器仅参考该建议，是否展开取决于函数大小、调用频次、优化等级及取地址等条件；含static局部变量、递归或函数指针赋值时通常忽略；debug模式下基本无效且破坏调试体验；跨TU内联需头文件定义并遵守ODR。
inline 函数不一定会被内联
编译器对 inline 关键字只有“建议权”，不是强制指令。是否真正展开，取决于函数体大小、调用频次、优化等级（如 -O2）、是否有取地址操作等。比如含 static 局部变量、递归调用、或函数地址被赋给函数指针时，绝大多数编译器会直接忽略 inline 建议。
常见误判现象：g++ -S 查看汇编后发现函数仍以 call 指令调用；或 nm 检查符号表发现该函数仍有外部可见符号（说明未被完全内联）。
内联引发的代码膨胀真实存在且可量化
每次调用点都复制一份函数体指令，而非复用同一份代码段。尤其在模板 + 内联组合场景下（如 std::vector::size() 这类 trivial getter），每个实例化类型都会生成独立副本，导致目标文件体积明显上升。
- 用
size -t或readelf -S观察 .text 节增长 - 开启
-frecord-gcc-switches配合gcc -Q --help=optimizers查看实际内联决策 - Clang 可加
-mllvm -print-after-all输出 IR 级内联日志（慎用，输出极多）
debug 构建下 inline 几乎失效且破坏调试体验
默认 -O0 时，GCC/Clang 基本禁用所有自动内联，即使写了 inline 也大概率不展开；而手动加 __attribute__((always_inline)) 又会导致 GDB 单步跳转异常——因为源码行与机器指令不再一一对应，step 可能直接跳过整个函数体。
立即学习“C++免费学习笔记（深入）”；
更隐蔽的问题：内联后，原本在函数入口设置的断点会失效；info registers 中的返回地址可能指向调用者内部，而非函数起始位置。
跨编译单元内联需定义可见，头文件污染风险高
inline 函数必须在每个使用它的 TU（translation unit）中**有且仅有一次定义**，否则违反 ODR。这意味着它几乎只能写在头文件里，且不能依赖仅在 .cpp 中定义的 static 变量或未声明的辅助函数。
典型陷阱：
- 头文件中
inline void f() { helper(); }，但helper()仅在某 .cpp 中定义 → 链接失败 - 多个头文件间接包含同一
inline函数定义 → 若未加inline或static，ODR 违反 - 模板特化 +
inline混用时，显式特化必须也在头文件中声明为inline，否则各 TU 特化版本可能不一致
内联不是银弹，真正影响性能的往往是缓存局部性、分支预测失败或内存访问模式；盲目标记 inline 可能换来更大的二进制体积和更差的指令缓存命中率，尤其是当函数体超过 10–15 行或含循环时，编译器通常已拒绝内联——但开发者写的 inline 还是留在了头文件里，持续制造冗余定义。
