内联函数只是向编译器提出建议，是否内联由编译器根据函数大小、调用频率和优化级别等决定；适合手动加inline的包括头文件中的短小辅助函数、类内定义成员函数、模板函数等。
内联函数不是“只要加 inline 就一定变快”，它只是向编译器提出一个建议，是否真正内联由编译器决定；盲目标记反而可能增大代码体积、降低指令缓存命中率。
哪些函数适合加 inline 关键字
编译器对内联的决策高度依赖函数体大小、调用频率和优化级别（如 -O2 或 -O3）。真正适合手动加 inline 的，通常是：
- 定义在头文件中、被频繁调用的短小辅助函数（比如
max(a, b)、is_even(n)） - 类内定义的成员函数（C++ 标准规定隐式为
inline，无需显式写） - 模板函数（通常必须定义在头文件里，
inline可避免 ODR 违规） - 不包含循环、递归、
try/catch、或复杂表达式的函数
inline 不起作用的常见原因
即使写了 inline，编译器也可能忽略。典型情况包括：
- 函数体过大（例如超过 10–20 行逻辑，或含
for循环） - 启用了低优化等级（如
-O0），此时大多数编译器直接禁用内联 - 函数地址被取过（例如赋给函数指针、或传入
std::function），编译器必须保留可寻址版本 - 跨编译单元调用且未启用 LTO（Link-Time Optimization）时，定义不在调用点可见
如何验证某个函数是否真的被内联了
不能只看源码有没有 inline，得看生成的汇编。以 GCC/Clang 为例：
g++ -O2 -S -o func.s main.cpp
打开 func.s，搜索该函数名：如果找不到对应函数标签（如 _Z3fooi），且其逻辑被展开到调用处，则说明已内联。也可用调
- 在调用点设断点，
step into进不去函数体 → 很可能已内联 - 用
objdump -d a.out | grep -A10 'call.*foo'，若没看到call指令而是直接看到 mov/add 等操作 → 已展开
比 inline 更有效的性能手段
现代 C++ 中，过度关注 inline 往往本末倒置。真正影响执行效率的通常是：
- 数据局部性（结构体字段顺序、数组 vs 链表）
- 分支预测失败（比如随机条件跳转）
- 缓存行对齐与 false sharing（多线程下）
- 不必要的拷贝（优先用
const T&或移动语义） - 编译器优化开关本身（
-O2 -march=native -flto比手加一百个inline更管用）
内联只是编译器优化流水线中的一环，它解决不了算法复杂度问题，也掩盖不了糟糕的内存访问模式。
