inline函数不一定内联，它只是编译器建议；是否内联取决于函数大小、调用频率、优化等级（如-O2）、是否取地址、有无异常处理或调试模式等因素。
inline 函数什么时候真能被编译器内联
它不是“写上 inline 就一定内联”，而是给编译器一个建议。是否真内联，取决于函数体大小、调用频次、优化等级（比如 -O2 下更积极）、是否有取地址操作（&func 会强制取消内联）。
常见错误现象：gdb 调试时仍能看到函数调用栈帧；或者 objdump 查看汇编发现仍有 call 指令——说明没内联成功。
- 简单访问器（如
get_x()）大概率内联；含循环、递归、异常处理的几乎不会 - 定义必须在头文件里（否则链接时报
undefined reference），因为编译器需要看到函数体才能决定是否内联 -
static inline是安全兜底：避免多定义问题，也适用于只在单个 .cpp 里用的场景
和宏（#define）比，inline 解决了哪些实际问题
宏是文本替换，不检查类型、不进调试器、容易因括号缺失引发运算符优先级 bug；inline 是真正的函数，有作用域、类型检查、可断点调试。
使用场景：封装简单计算逻辑（比如坐标距离平方 dist2(x1,y1,x2,y2)），又不想付出函数调用开销。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 宏写成
#define SQUARE(x) x*x，调用SQUARE(a+b)展开为a+b*a+b——错得离谱；inline int square(int x) { return x*x; }没这问题 - 宏无法重载；
inline函数可以像普通函数一样重载、模板化 - 宏不能捕获局部变量（除非用 GNU 扩展语句表达式）；
inline可以正常访问 this、参数、自动变量
inline 和 constexpr 的边界在哪
constexpr 要求函数能在编译期求值；inline 关注运行期调用开销。二者不互斥，但目标不同。
性能影响：标记 constexpr 的函数若满足条件（比如参数全为字面量），会被编译器提前算出结果，彻底消除运行时开销；而 inline 仅省去 call/ret 指令，仍要执行计算。
- 想做编译期计算（比如数组长度、位掩码生成），优先用
constexpr；inline不保证编译期求值 - C++14 起
constexpr函数允许更复杂逻辑（if、循环），但仍有严格限制（不能有 new、static 变量等） - 两者可共存：
constexpr inline int add(int a, int b) { return a + b; }——既支持编译期，也利于运行期内联
链接时报 undefined reference 到 inline 函数
根本原因是：inline 函数定义没暴露给所有使用它的编译单元。C++ 标准要求 inline 函数定义必须在每个包含它的 TU（translation unit）中可见。
典型错误：把 inline 函数声明放 .h，定义放 .cpp ——其他 .cpp 包含头文件后，只看到声明，看不到定义，链接失败。
- 正确做法：定义直接写在头文件里（.h 或 .inl），且确保该头文件被所有调用者包含
- 如果函数体较大或依赖其他实现细节，可用
inline声明 + 在 .cpp 中定义，但必须加static（变成内部链接），否则违反 ODR（One Definition Rule） - Clang/GCC 下可用
__attribute__((always_inline))强制内联，但慎用：可能增大代码体积、破坏 CPU 指令缓存局部性
真正难的是权衡：过度内联会让代码膨胀，反而降低 cache 命中率；而该内联的地方没加，又留着无谓的 call 开销。与其盲目加 inline，不如先用 perf 或 VTune 看热点，再针对性优化。
