inline函数必须定义在头文件中以确保各翻译单元可见，否则链接失败；类内定义的成员函数默认inline；inline仅为编译器提示，不保证内联。
inline 函数必须在每个使用它的翻译单元里可见
这意味着你不能像普通函数那样只在 .cpp 文件里定义 inline 函数，否则链接时会报 undefined reference。绝大多数情况下，inline 函数得写在头文件里（.h 或 .hpp），让所有包含它的源文件都能看到定义。
常见错误现象：
- 在
.cpp中定义inline void f() { }，然后在另一个.cpp里调用 —— 链接失败 - 头文件里只声明
inline void f();，定义放在别处 —— 同样链接失败
正确做法：
-
inline关键字写在函数定义前（声明+定义一起） - 定义直接放在头文件中（哪怕只有几行）
- 如果函数体较长或依赖其他头文件，确保头文件包含关系完整且无循环依赖
类内定义的成员函数默认 inline
在类定义内部直接写出函数体，编译器自动视其为 inline，无需显式加 inline 关键字。但这不等于“一定会被内联”，只是给了编译器内联提示。
例如：
struct S {
int x = 0;
int get() const { return x; } // ✅ 默认 inline
void set(int v) { x = v; } // ✅ 同样默认 inline
};
注意：
- 即使加了
inline（如inline int get() const { ... }），效果一样，冗余但合法 - 若把定义挪到类外（
.cpp），就必须显式加inline，且仍需放在头文件中（不能放.cpp） - 模板函数天然适合 inline，但模板本身不是 inline 的替代品；二者解决的问题不同
inline 不是性能银弹，现代编译器通常自己决定是否内联
inline 只是一个建议，C++ 标准不保证函数一定被内联。编译器会根据函数大小、调用频率、优化等级（如 -O2）等综合判断。过度标记 inline 可能导致代码膨胀，反而降低缓存命中率。
适用场景：
- 非常短小的访问器（getter/setter）、包装器
- 频繁调用、逻辑简单、无循环/分支的辅助函数
- 需要避免函数调用开销的关键热路径（但应先 profile 验证）
不适用场景：
- 含
static局部变量的函数（内联后语义可能变化） - 递归函数（除非编译器支持尾递归优化并展开）
- 函数体超过十几行或含复杂控制流
inline 和 static inline 在头文件里的区别
在头文件中，inline 和 static inline 都能避免 ODR（One Definition Rule）违规，但语义不同：
-
inline：允许多个定义，链接器确保只保留一份（外部链接） -
static inline：每个翻译单元生成一份独立副本（内部链接），适用于不需要跨文件共享符号的场景（比如仅用于当前头文件的工具函数）
示例：
// utils.hpp
inline int add(int a, int b) { return a + b; } // ✅ 外部链接，安全用于多个 .cpp
static inline int square(int x) { return x * x; } // ✅ 内部链接，各 .cpp 自己一份
容易踩的坑：
- 误以为
static inline比inline“更 inline”——其实内联决策与static无关 - 在头文件里用
static（不带inline）定义函数——会导致每个.cpp有一份，但无法跨文件调用，且不满足 ODR（C++17 起允许，但仍是反模式）
真正麻烦的是跨翻译单元的符号一致性，以及误把 inline 当作强制指令来用。它本质是个链接期约定，不是编译期开关。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
