inline函数不一定内联，因编译器仅视其为建议，是否内联取决于优化等级、函数复杂度及调用上下文；高频调用+非平凡函数体才真正导致代码膨胀。
inline 函数为什么不一定真内联
编译器对 inline 关键字只有“建议权”，不是强制指令。是否真正展开为内联代码，取决于函数体复杂度、优化等级、调用上下文等因素。比如在 -O0（无优化）下，绝大多数 inline 函数都不会被内联；而递归函数、含虚函数调用、或过大函数体（如超过几十行），即使加了 inline，编译器也大概率忽略。
代码膨胀的真实触发条件
内联本身不直接导致膨胀，真正危险的是「高频调用 + 非 trivial 函数体」。例如一个 20 行的 inline 函数，在 100 个不同翻译单元中被包含并调用，每个调用点都可能复制一份代码副本——尤其当它被放在头文件里且被多个 .cpp 文件 include 时。
- 避免在头文件中定义复杂
inline函数；优先用constexpr或模板特化替代 - 对仅用于单个源文件的函数，改用
static inline，限制链接可见性 - 用
objdump -d或nm --defined-only检查目标文件中是否出现重复符号
与宏、constexpr、lambda 的关键区别
inline 是作用于函数的链接属性，和宏的文本替换、constexpr 的编译期求值、lambda 的闭包生
成，解决的是不同层面的问题：
- 宏没有类型检查，
inline函数有完整语义分析 -
constexpr函数可参与编译期计算，但要求严格（如不能有副作用），inline无此限制 - 捕获变量的 lambda 默认不可内联（除非是空捕获且编译器激进优化），而命名
inline函数更可控
inline int square(int x) { return x * x; } // 安全、类型安全、可调试
#define SQUARE(x) ((x)*(x)) // 可能多次求值，无类型约束
constexpr int square_c(int x) { return x * x; } // 编译期可用，但 x 必须是常量表达式调试和性能验证不能只看关键字
加了 inline 不代表性能提升，甚至可能因指令缓存压力变慢。真实收益需结合 profile 数据判断：
- 用
perf record -e cycles,instructions对比内联前后的热点分布 - 调试时，GCC/Clang 的
-fkeep-inline-functions可保留内联函数符号，方便 gdb 断点 - 注意：LTO（Link Time Optimization）下，跨文件内联才真正生效，单文件编译时很多内联机会被错过
最常被忽略的一点：inline 解决的是「调用开销」，但如果函数本身耗时远高于 call/ret 指令（比如含内存分配或锁），内联几乎没意义。
