inline 是向编译器提出的内联请求而非强制指令，是否生效取决于编译器优化策略；适合短小、高频、无副作用的函数，如简单 getter/setter；头文件中定义普通函数需加 inline 避免 ODR 错误；盲目使用可能因代码膨胀降低缓存命中率。
inline 函数能避免函数调用开销，但只在编译器决定“展开”时才生效
inline 关键字本质是向编译器提出内联请求，不是强制指令。现代编译器（如 GCC、Clang、MSVC）会忽略大部分 inline 声明，转而基于自身优化策略（如函数大小、调用频次、是否含循环/递归）决定是否真正展开。所以加了 inline 不等于一定变快，甚至可能因代码膨胀拖慢缓存命中率。
适合 inline 的典型场景：短小、高频、无副作用的访问器或简单计算
比如 getter/setter、std::max 小封装、坐标分量访问等。这类函数体通常不超过 3–5 行，不含分支预测难的 if、不含虚函数调用、不抛异常、不涉及动态内存操作。
-
inline int getX() const { return x_; }—— 合理；展开后就是一条 mov 指令 -
inline std::string getName() { return name_; }—— 不合理；构造std::string开销大，编译器几乎必拒绝内联 -
inline void log(const char* msg) { fprintf(stderr, "%s\n", msg); }—— 危险；I/O 是重操作，且fprintf本身巨大，强行标记inline无意义
常见误用：头文件中定义非 inline 普通函数，引发 ODR 链接错误
这是 C++ 新手最常踩的坑。如果在头文件里写：
int helper() { return 42; } // ❌ 缺少 inline多个 .cpp 包含该头，每个编译单元都会生成一个 helper 定义，链接时报 multiple definition of 'helper'。正确做法是加 inline（C++17 起允许 inline 变量和函数在头文件中定义多次）：
立即学习“C++免费学习笔记（深入）”；
inline int helper() { return 42; } // ✅ OK或者改用 static（但会导致每份副本独立，无法跨 TU 共享符号），或只在头文件中声明、在单个 .cpp 中定义。
性能影响要看实际汇编，别靠直觉判断是否该加 inline
加 inline 后反而变慢的情况并不少见：函数体被复制多份 → 指令缓存（i-cache）压力增大 → CPU 取指延迟上升；尤其在热路径上大量内联相似小函数时，容易挤掉其他关键代码。
- 验证方法：用
g++ -O2 -S生成 .s 文件，搜索目标函数名是否还存在（若消失，说明被展开了） - 更可靠方式：用 perf 或 VTune 测量 L1-icache-misses 和 cycles/instruction，而非只看 wall-clock 时间
- 模板函数默认隐式 inline，无需手动加；类内定义的成员函数也隐式 inline，但同样受编译器最终决策约束
真正影响性能的，往往不是某处要不要加 inline，而是数据局部性、分支预测失败率、是否触发 vectorization —— 这些比手工内联重要得多。
