内联函数
概念
inline是一个建议，在调用函数时，编译器会根据函数体的大小来判断要不要内联（复制函数体过来，而不是普通函数的call）
结论
函数越小，编译器越喜欢内联；函数越大，编译器越倾向保留普通函数的 call
引子
在VS中，debug不会用任何优化，inline无效。release下会采用优化，但是对于inline声明的函数，这只是个建议。如果inline之后体积很大，编译器拒绝inline，采用call。
这是release模式下的inline，可以看见没有复制的效果
使用__forceinline 代替inline强制展开，可以认为是inline应该有的效果
下面还有很多，省略掉
一、什么是内联函数？
inline 的核心思想是：
允许编译器把函数调用直接替换成函数体，从而消除一次函数调用的抽象边界。
例如：
inline int add(int a, int b)
{
return a + b;
}
int x = add(1, 2);普通调用可能生成：
mov edi, 1
mov esi, 2
call add如果编译器决定内联，则可能直接变成类似：
mov eax, 3也就是说：
普通调用：
调用者
↓
call
↓
add()
↓
ret
↓
继续执行
内联：
调用者
↓
直接出现 add() 的计算逻辑但是要注意：
inline不是“强制内联指令”。
它只是告诉编译器：
“这个函数适合考虑内联。”
最终是否真的内联，由编译器优化器决定。
二、inline 为什么不一定真的内联？
编译器会综合考虑：
函数大小
调用频率
代码尺寸
优化级别
CPU架构
寄存器压力
指令缓存
分支结构例如：
inline int add(int a, int b)
{
return a + b;
}非常短，通常很适合内联。
而：
inline void heavy_compute(void)
{
// 几百行代码
}即使写了 inline，编译器也可能选择：
call heavy_compute因为强行展开可能导致代码体积急剧增加。
所以：
函数越小，通常越容易被内联；函数越大，越需要权衡。
三、Debug 和 Release 的区别
Debug 模式通常会关闭或降低优化级别：
Debug
↓
-O0 / 低优化
↓
尽量保持源代码结构
↓
方便调试因此你可能看到：
call add即使函数声明了：
inline也不一定展开。
Release 模式通常开启较高优化：
Release
↓
-O2 / -O3 等
↓
编译器进行大量优化
↓
可能自动内联而且即使你没有写 inline：
int add(int a, int b)
{
return a + b;
}优化器也完全可能自动把它内联。
所以：
现代 C/C++ 编译器通常不需要程序员到处写
inline，优化器自己就会判断。
四、__forceinline
以 MSVC 为例：
__forceinline int add(int a, int b)
{
return a + b;
}它比普通 inline 更强，表示：
强烈要求编译器进行内联。
但也不能简单理解成：
“只要写了
__forceinline，100% 就一定展开。”
编译器仍然可能因为某些限制无法实现。
因此应该把它理解成：
inline
↓
建议内联
__forceinline
↓
强烈要求内联而不是：
inline = 一定内联
__forceinline = 100%保证内联五、内联真正消除的是什么？
不要简单理解成：
“内联就是为了省掉
call和ret。”
更准确地说：
内联消除的是函数调用形成的优化边界，使编译器可以把调用者和被调用函数放在一起进行优化。
例如：
int add(int a, int b)
{
return a + b;
}
int x = add(10, 20);如果不内联，编译器需要保留函数调用边界。
而内联以后，优化器看到的可能直接是：
int x = 10 + 20;于是它甚至可以继续优化成：
int x = 30;这就是内联非常重要的一点：
真正的价值不仅仅是减少
call/ret，而是暴露更多上下文，让后续优化有机会发生。
六、函数调用到底有什么开销？
函数调用的开销不能简单归结为：
call很慢，因为流水线被清空。
现代 CPU 对 call/ret 有专门的预测机制。
例如：
call
↓
返回地址预测
↓
ret
↓
Return Address Stack（RAS）如果预测正确，call/ret 本身可能非常便宜。
真正可能产生开销的是整个调用约定和调用边界。
例如：
函数调用
├── 参数传递
├── 返回值处理
├── 保存必要的寄存器
├── 栈空间调整
├── 可能的内存访问
└── 间接调用预测等但这些也不是每次都会全部发生。
现代编译器非常聪明：
没有需要保存的寄存器
↓
不保存
没有栈变量
↓
可能不建立栈帧
调用非常简单
↓
可能直接优化掉
函数可内联
↓
整个调用消失所以：
不要把“函数调用 = 固定几十个周期”当成定律。
实际成本取决于具体 CPU、ABI、编译器生成的代码以及缓存/预测状态。
七、为什么过度内联反而可能变慢？
假设一个函数：
void heavy_compute(void)
{
// 300 字节机器代码
}循环调用：
for (int i = 0; i < 10000000; i++)
{
heavy_compute();
}如果强制内联：
循环体
↓
300 字节代码
↓
重复执行可能造成：
代码体积膨胀
↓
指令缓存压力增加
↓
I-Cache 命中率下降
↓
取指效率下降
↓
性能反而下降因此：
内联不是越多越快。
编译器实际上在做一个权衡：
内联收益
VS
代码膨胀成本八、为什么小函数特别适合内联？
例如：
static inline int max(int a, int b)
{
return a > b ? a : b;
}如果不内联：
参数准备
↓
call
↓
比较
↓
ret如果内联：
直接比较
↓
继续执行更重要的是，编译器可以继续结合上下文优化。
例如：
int x = max(10, 20);内联之后可能进一步变成：
int x = 20;甚至：
直接使用常量 20所以内联的价值可以概括为：
内联
↓
消除调用边界
↓
暴露函数内部逻辑
↓
常量传播 / 死代码消除 / 传播分析 / 指令优化
↓
获得更好的最终机器码九、函数指针是不是不能内联？
不能简单这么说。
例如：
int (*func_ptr)(int);
func_ptr = another_sum;
int result = func_ptr(5);如果编译器无法确定：
func_ptr
到底指向哪个函数？那么就必须保留间接调用：
mov rax, [func_ptr]
call rax因为运行时函数地址可能发生变化。
但是，如果编译器能够证明：
func_ptr = another_sum;并且之后没有任何可能改变它，那么优化器可能直接把：
func_ptr(5)转换成：
another_sum(5)然后进一步内联。
因此真正的判断标准是：
编译器能不能在编译期确定实际调用目标。
而不是：
“用了函数指针就绝对不能内联。”
十、虚函数为什么可能无法内联？
例如：
class Base
{
public:
virtual void run();
};调用：
Base *p = get_object();
p->run();如果运行时 p 可能指向：
DerivedA
DerivedB
DerivedC那么编译器可能无法提前确定：
到底调用哪个 run()？于是需要通过虚函数表：
p
↓
vptr
↓
vtable
↓
run()最终形成间接调用。
但如果编译器能够证明：
Base *p = new DerivedA;
p->run();并且整个程序中没有其他可能性，那么现代优化器可能进行：
Devirtualization（去虚拟化）
把动态调用变成确定调用，然后继续内联。
所以：
虚函数不是“绝对不能内联”，而是运行时动态分派会增加内联的难度。
十一、宏函数和内联函数的区别
宏：
#define SQUARE(x) ((x) * (x))本质是：
源代码
↓
预处理器
↓
文本替换
↓
编译器例如：
SQUARE(a + 1)直接变成：
((a + 1) * (a + 1))宏没有真正的函数类型和参数类型检查。
而：
inline int square(int x)
{
return x * x;
}会经过正常的：
词法分析
↓
语法分析
↓
类型检查
↓
中间表示
↓
优化
↓
机器码生成因此：
宏
↓
预处理阶段文本替换
inline
↓
正常函数
↓
编译器优化阶段决定是否展开这也是为什么内联函数通常比宏函数更加安全。
十二、嵌入式中的 static inline
在 STM32 驱动中非常常见：
static inline uint32_t get_bit(uint32_t reg, uint32_t bit)
{
return (reg >> bit) & 1U;
}这里其实有两个概念：
static
↓
限制函数的链接范围
↓
只在当前 .c 文件可见
inline
↓
告诉编译器这个函数适合考虑内联两者解决的问题完全不同：
static → 链接/可见性
inline → 优化/内联所以不要把 static inline 理解成一个整体关键字。
十三、最终理解
可以把整个过程记成：
inline
│
├── 不是强制内联
│
├── 编译器根据上下文决定
│
└── 真正价值不只是省 call/ret
│
▼
消除调用边界
│
▼
暴露更多优化机会
│
┌───────┼────────┐
▼ ▼ ▼
常量传播 死代码 寄存器优化
等而内联也存在代价：
内联
↓
减少调用开销
增加优化机会
↓
但是
↓
代码体积膨胀
↓
I-Cache 压力增加
↓
过度内联可能反而变慢一句话记忆：
内联不是简单的“把函数复制过来”，而是让编译器消除函数调用边界，把调用者和被调用者放到同一个优化上下文中；它可能减少调用开销，更重要的是为常量传播、死代码消除、寄存器分配等进一步优化创造条件。
