inline函数仅在编译器综合评估后（如函数体小、高频调用、-o2以上优化、无取地址等）才真正内联；否则仍生成call指令，且头文件中定义是必要前提。
inline 函数什么时候真的会被内联？
编译器只把 inline 当作建议，不是指令。它是否展开，取决于函数体大小、调用频率、优化等级（比如 -O2 下更积极）、是否有取地址行为（&func 会强制不内联）。
常见错误现象：加了 inline 却发现汇编里还是 call 指令；或者头文件里定义了 inline 函数，但链接时报 multiple definition —— 这是因为没放头文件，或误用了非 inline 的普通定义。
- 必须在所有使用它的翻译单元中可见，所以
inline函数通常定义在头文件里 - 避免在函数体内有复杂控制流（如循环嵌套、递归调用），编译器大概率放弃内联
- 调试模式（
-O0）下基本不内联，别指望断点能停进“内联后”的逻辑里
inline 和 static inline 有什么区别？
关键在链接属性：inline 允许跨 TU 多次定义（ODR-compliant），而 static inline 每个 TU 各有一份副本，互不影响。
使用场景：写工具函数（比如 clamp、is_power_of_two）时，用 inline 更合适；但如果函数依赖 TU 局部的 static 变量，或你明确不想暴露符号，就用 static inline。
立即学习“C++免费学习笔记（深入）”；
-
inline函数名会出现在符号表中（尽管可能未被引用），static inline不会 - 模板函数默认就是
inline行为，不用显式加（但加了也不报错） - 类内定义的成员函数自动带
inline属性，哪怕没写关键字
哪些情况加 inline 反而有害？
盲目标记会导致代码膨胀，尤其在小函数高频调用 + 低优化等级下，反而增加 cache miss 和指令体积。
性能影响明显的情况：函数虽短但调用点极多（如 vector 的 size()），内联后生成大量重复指令；或函数含虚函数调用、异常处理、std::string 构造等隐式开销，内联只是把开销“复制”到各处。
- 含
try/catch的函数，GCC/Clang 在-O0下几乎从不内联 - 返回
std::vector或其他大对象的函数，内联可能让 RVO 失效 - 调试时想单步跟踪某个逻辑，加了
inline后调试器跳过该函数——这不是 bug，是预期行为
怎么验证一个函数是否真被内联了？
最直接方式是看编译后的汇编：g++ -O2 -S file.cpp，然后搜函数名。如果没对应函数体标签（如 _Z3foov:），且调用点直接展开指令，则说明已内联。
也可以用编译器提示：GCC 支持 __attribute__((always_inline)) 强制（但失败时会警告），Clang 有 [[clang::always_inline]]；反过来，[[gnu::noinline]] 可用于排除干扰。
-
nm a.out | c++filt | grep your_func_name—— 如果没输出，大概率内联成功（也可能被优化掉） - 不要依赖 IDE 的“转到定义”来判断，那只是语法层面跳转，和实际代码生成无关
- Profile 数据（如 perf）里看不到该函数的 self-time，并不等于被内联——也可能是被整个优化掉了
inline 关键字本身重要得多。 
