inline函数需定义在头文件中且函数体简单（无循环、异常等）才更可能被内联；编译器仅视其为建议，实际取决于优化等级和函数复杂度。
inline 函数怎么写才真正生效
编译器不保证 inline 关键字声明的函数一定被内联——它只是建议。真正是否展开，取决于函数体复杂度、调用上下文、优化等级（如 -O2）和编译器判断。
常见错误是把含循环、递归、try/catch、虚函数调用或取地址操作（&func）的函数标为 inline，这些基本会让编译器直接忽略内联请求。
- 简单访问器/修改器（如
get_x()、set_y(int v)）最适合作为inline - 定义必须在头文件里：否则链接时可能报
undefined reference（因为内联后不生成符号） - 用
gcc -S -O2或clang -S -O2生成汇编，搜call指令是否存在，是验证是否内联的最可靠方式
为什么加了 inline 还有链接错误
典型错误现象：multiple definition of 'foo()' 或 undefined reference to 'bar()'。
根本原因：C++ 的 ODR（One Definition Rule）要求非内联函数在程序中只能有一个定义；而 inline 函数允许在多个翻译单元中定义，但前提是——所有定义必须完全相同，且必须出现在每个用到它的 TU（即头文件中）。
立即学习“C++免费学习笔记（深入）”；
- 别在 .cpp 里写
inline void f() { ... }然后只在那儿定义一次——这违反 ODR，链接失败 - 头文件中定义
inline函数时，避免依赖未声明的静态局部变量或静态数据成员（它们会引发 ODR-violating 的隐式内部链接问题） - 模板函数天然内联语义，一般不用显式加
inline；加了也无害，但没必要
inline 和宏（#define）到底差在哪
两者都可避免函数调用开销，但本质完全不同：宏是文本替换，inline 是编译器控制的语义级展开。
宏容易踩坑：参数多次求值（MAX(i++, j++)）、类型不安全、无法调试、作用域混乱；而 inline 函数有完整类型检查、支持重载、能设断点、参与 ADL 和 SFINAE。
- 用
inline constexpr int square(int x) { return x * x; }替代#define SQUARE(x) ((x)*(x))，更安全且可被常量折叠 - 涉及复杂逻辑（比如带分支或异常处理）时，宏完全不可维护，
inline函数仍是首选 - 宏没有作用域，
inline函数遵守命名空间和类作用域规则
Clang/GCC 对 inline 的实际行为差异
不同编译器对 inline 的“建议权重”不同，尤其在低优化等级下（如 -O0）：Clang 默认几乎忽略 inline，GCC 可能仍尝试简单展开。
更重要的是：现代编译器（特别是 GCC 5+ / Clang 6+）在 -O2 及以上会自动内联小函数，哪怕没写 inline；反过来，写了 inline 也不代表一定比自动内联更优。
- 用
__attribute__((always_inline))（GCC/Clang）或[[gnu::always_inline]]强制内联，但可能增大代码体积、破坏 CPU 指令缓存局部性 -
__attribute__((noinline))用于调试或性能对比，防止编译器“偷偷优化掉”你想要观测的调用 - 跨平台项目慎用编译器扩展；标准
inline是唯一可移植写法
真正影响内联效果的，从来不是你写了几个 inline，而是函数体是否足够轻量、是否在头文件中定义、以及构建时是否启用了对应优化等级。手动标记前，先看汇编输出——这是唯一不骗人的依据。
