编译器自主决策内联，inline仅为建议而非强制；实际是否内联取决于函数大小、调用上下文、优化级别及LTO启用情况，跨编译单元需头文件定义，强制内联风险高且应慎用。
编译器自己决定是否内联，你没法手动实现“内联决策算法”——那属于 GCC/Clang 的优化器内部逻辑，不暴露给用户。但你可以通过控制信号、约束条件和构建配置，实质性影响它的决策路径，并规避代码膨胀。
inline 关键字只是建议，不是开关
写了 inline 不代表函数一定被展开；没写也可能被自动内联（比如 O2 下的 trivial getter）。编译器真正看的是：
- 函数体是否短小（通常 ≤10 行、无循环/递归/异常处理）
- 调用点是否在同一个编译单元（跨 TU 时 inline 定义必须在头文件中）
- 是否存在函数指针取址（
&func会直接禁用内联） - 是否启用了 LTO（Link-Time Optimization），它能跨目标文件做更激进的内联
头文件里定义成员函数必须加 inline 或放类体内
否则多个 .cpp 文件包含该头，链接时报 multiple definition 错误。这是因为 ODR（单一定义规则）要求：非内联函数在程序中只能有一份定义。
- 类体内定义：自动隐式
inline，无需写关键字 - 类外定义：必须显式写
inline，且要放在头文件中（不能放 .cpp） - 模板函数：天然满足 ODR，不需要也不应该加
inline
强制内联只用于极少数确定场景
__attribute__((always_inline))（GCC/Clang）或 [[gnu::always_inline]] 可绕过编译器判断，但风险极高：
立即学习“C++免费学习笔记（深入）”；
- 递归函数加
always_inline会导致编译失败（GCC 报错inlining failed in call to always_inline） - 大函数强制内联极易引发指令缓存失效，实测在 Cortex-M4 上可能反而慢 15%+
- 一旦用了，后续任何优化级别（-O0/-O3）都生效，调试时难以追踪调用栈
仅建议用于裸机驱动中单条寄存器写入这类确定性极强的小操作，例如：__attribute__((always_inline)) static inline void set_led_on() { GPIOB->BSRR = 1
LTO 是控制膨胀与性能平衡的实际手段
启用 -flto 后，链接器能看到所有目标文件的 IR，能做全局内联裁剪：对高频小函数积极内联，对低频大函数保留调用，同时合并重复的内联副本。
- 不开启 LTO 时，每个 .o 文件独立决策，容易重复膨胀
- 开启后需配合
-O2或更高，否则 LTO 几乎不触发内联 - 嵌入式项目注意：LTO 增加链接时间，且部分旧版 arm-none-eabi-gcc 对 LTO 支持不稳
真正难控的不是“怎么让编译器内联”，而是“怎么让它别在不该内联的地方膨胀”。这需要结合 objdump -d 看汇编、用 size 对比节大小、并在关键路径上用 __attribute__((noinline)) 主动阻断——这些才是工程中实际可操作的锚点。
