内联函数是编译器优化建议而非强制指令，是否内联取决于函数大小、调用频次、递归、取地址等多因素；取地址操作（&func）将导致内联失效；必须在头文件中定义完整函数体以满足odr。
内联函数只是建议，不是指令
编译器把 inline 关键字当“请求”，不是强制命令。它会综合函数体大小、调用频次、是否递归、是否有取地址操作等因素做权衡。哪怕你写了 inline，只要编译器觉得内联后代码膨胀太大或优化收益低，就直接忽略。
- 常见错误现象：
gdb调试时仍能看到函数调用栈帧，或objdump反汇编发现仍有call指令 - 使用场景：适合短小、高频、无副作用的计算逻辑（比如
get_x()、max(a, b)），不适用于含循环、switch或大量局部变量的函数 - 参数差异：
inline对模板函数影响更小——模板实例化时编译器更容易判断是否值得内联；而普通非模板函数若跨编译单元定义，链接时可能根本看不到函数体
函数地址被取用就大概率失效
只要你对一个 inline 函数做了取地址操作（&func_name），绝大多数编译器（GCC/Clang/MSVC）都会放弃内联，因为它必须为该函数生成一份可寻址的实体代码。
- 常见错误现象：声明为
inline的函数，却在调试器里能设断点、能打印&func_name的值，说明它已被具现化 - 使用场景：避免在头文件中对
inline函数取地址；如果确实需要函数指针，不如改用constexpr+ lambda（C++17+）或普通非内联函数 - 性能影响：取地址本身不耗时，但导致内联失效后，每次调用都多一次
call/ret开销，对微秒级热路径影响明显
不同编译器和优化等级表现不一致
inline 的实际效果高度依赖编译器版本和 -O 级别。不开优化（-O0）时，GCC 和 Clang 基本无视 inline；而 MSVC 在 /Od 下也可能保留部分内联，但不可靠。
- 常见错误现象：开发时用
-O0测试，以为函数没内联是“写错了”，切到-O2后才发现它早被自动内联了（甚至没加inline关键字） - 兼容性影响：Clang 对短函数更激进，GCC 在
-O3下可能做 IPA（过程间分析）后内联跨文件函数，但需配合-flto - 实操建议：用
__attribute__((always_inline))（GCC/Clang）或__forceinline（MSVC）强行要求——但仅限极少数确定收益且可控的场景，否则易引发代码膨胀
头文件里定义 inline 函数要小心 ODR
内联函数必须在每个使用它的翻译单元里有**完全相同的定义**，否则违反 ODR（One Definition Rule）。这要求你把它完整写在头文件里，而不是只声明、在 .cpp 里定义。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：头文件只写
inline void f();，.cpp 里写实现 → 链接时报undefined reference to f() - 使用场景：所有
inline函数定义（包括函数体）必须出现在头文件中；若用 C++17，可改用inline变量或constexpr函数替代部分需求 - 容易被忽略的地方：类内定义的成员函数默认
inline，但如果在类外定义又加了inline，就必须确保头文件包含该定义，且不能重复包含导致重定义
