inline函数真正起作用需满足：函数体简单、未取地址、未跨编译单元调用、开启优化（如-O2），且定义必须在头文件中；否则仅解决ODR问题，不保证内联。
inline 函数怎么写才真正起作用
编译器不保证 inline 函数一定被内联，它只是个建议。真正生效需要同时满足：函数体足够简单、未取地址、未跨编译单元调用、未开启某些优化抑制选项（如 -O0）。
常见错误是把几十行带循环/虚函数调用的函数标成 inline，结果编译后仍是普通函数调用——你看到的 inline 只是让链接器能容忍多份定义，不是性能优化。
- 推荐只对短小、高频、无副作用的函数使用，比如 getter/setter：
inline int get_x() const { return x; } - 定义必须在头文件里（否则其他 TU 无法看到函数体），且所有包含该头的编译单元都会生成一份副本
- 如果函数在 .cpp 里定义并加
inline，又没被其他文件包含，那inline就纯属冗余
为什么加了 inline 还报 “multiple definition” 错误
这是典型的链接阶段错误，说明你把 inline 函数定义放到了 .cpp 文件里，或者虽然放在头文件但没加 inline（或用了 C++17 之前的旧标准，未启用 inline 语义）。
inline 的核心作用之一就是放宽 ODR（One Definition Rule）：允许同一函数在多个编译单元中定义，只要定义完全一致。但它只对 inline 函数、模板、constexpr 函数等有效。
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
int helper() { return 42; }放在头文件中（没加inline）→ 每个包含它的 .cpp 都生成一个helper符号 → 链接时报错 - 正确写法：
inline int helper() { return 42; }放在头文件中 → 合法，链接器接受多份相同定义 - C++17 起支持
inline变量，类似逻辑，但函数仍是主力场景
inline 和宏（#define）到底差在哪
本质区别是：宏是文本替换，inline 是编译器参与的函数调用优化。前者没类型检查、不进调试器、可能重复求值；后者有完整语义、可断点、参数只计算一次。
比如 #define SQUARE(x) (x * x) 在 SQUARE(i++) 中会出问题；而 inline int square(int x) { return x * x; } 安全得多。
- 宏能做
inline做不了的事（如字符串化、拼接 token），但不该用来替代简单函数 - 现代 C++ 中，除了极少数系统编程场景，优先用
inline+ constexpr 替代宏 - 注意：
inline不改变函数签名或调用约定，而宏可能隐式改变求值顺序和作用域
Clang/GCC/MSVC 对 inline 的实际处理差异
三大编译器都遵守标准语义，但内联决策策略不同：GCC 更激进（尤其 -O2 以上），Clang 倾向保守，MSVC 在 /Ob2 下才尝试跨函数内联。这些不影响 inline 的 ODR 行为，只影响是否真展开。
真正要注意的是：没有统一方式强制内联。__attribute__((always_inline))（GCC/Clang）或 __forceinline（MSVC）能绕过编译器判断，但滥用会导致代码膨胀、缓存失效，甚至因栈溢出崩溃。
- 不要用
always_inline标记递归函数或大函数 - 调试时（
-O0）几乎所有inline都被忽略，别指望单步进去 - 检查是否真内联：看汇编输出（
gcc -S）或编译器诊断（gcc -fopt-info-vec-optimized）
最常被忽略的一点：inline 解决的是链接层面的多定义问题，不是性能银弹。很多人加了 inline 就以为“快了”，其实连函数体都没被展开——得看生成的汇编，而不是源码里的关键字。
