嵌入式现代 C++教程——内联函数与编译器优化¶
在嵌入式开发中，inline 这个关键字几乎是每个工程师都会用到的东西。它看起来简单直接，甚至带着一点“性能保证”的意味：函数短、调用频繁、对时序敏感，那就 inline 掉，似乎天经地义。
对，在过去，inline这个关键字的确是这个作用，但是实际上，在现代C++的今天，在编译器的优化做的非常出色的现在，inline 并不是性能优化的按钮，它甚至经常什么都没做。
inline 从一开始，就不是为“快”而生的¶
从语言层面来说，inline 的核心作用其实非常克制。现代的 C++ 标准并没有承诺“你写了 inline，编译器就一定展开函数体”。它真正保证的事情只有一件：允许该函数在多个翻译单元中出现定义，而不违反 ODR。
这也是为什么大量头文件中的小函数、模板函数、traits 工具函数，天然就带着 inline 的气质。它解决的是“链接层面的问题”，而不是“性能问题”。至于是否真的发生内联，那完全是编译器的自由裁量权。在现代编译器面前，inline 更像是一句“我觉得你可以考虑展开”的建议，而不是命令。
那嵌入式里，函数调用真的慢吗？¶
很多关于 inline 的直觉，来自于对函数调用成本的恐惧。在 Cortex-M 这类架构上，一次函数调用确实意味着跳转、LR 保存、参数传递和返回路径恢复。你如果盯着汇编一条条看，很容易得出结论：这看起来不便宜。
问题在于，这个成本是否真的落在了你的性能瓶颈路径上。
在真实的嵌入式工程中，大量函数的时间消耗根本不在“调用本身”，而是在外设访问、总线等待、Flash 读取、Cache miss，甚至是中断抢占上。你为一个 GPIO 读取函数纠结要不要 inline，往往是在一个完全不重要的层级上做优化。
更关键的是，在开启优化（哪怕只是 -O2）之后，这类短小、无副作用、语义明确的函数，即使你不写 inline，编译器也几乎必然会自动内联。
今天的编译器在决定是否内联一个函数时，会综合考虑函数体大小、调用点数量、寄存器压力、指令 Cache 行为，甚至在开启 LTO 后跨文件分析调用关系。它掌握的信息，远比你在写代码时看到的那一点上下文要多。这也是为什么你经常会看到这样一种情况：你显式写了 inline，反汇编却发现函数依然存在；而你什么都没写，函数却悄无声息地被展开了。
展开成调用的inline其实不是很安全¶
如果说 PC 开发中，inline 最大的风险是“无感”，那么在嵌入式中，它真正的风险往往是代码体积膨胀。
内联的本质是复制。一个被频繁调用的小函数，如果在多个位置被展开，指令会被实实在在地复制多份。在 Flash 资源紧张的 MCU 上，这种复制是不可忽视的。更微妙的一点在于，代码变大不只是占 Flash，它还会影响指令 Cache 的局部性。即使在有 I-Cache 的内核上，过度内联也可能导致更多 Cache miss，最终表现为性能下降，而不是提升。
那 inline 什么时候才真正有价值？¶
在实践中，inline 真正体现价值的场景，往往不是“为了省掉一次函数调用”，而是为了消除抽象边界的成本。
例如模板函数、类型安全的寄存器访问封装、constexpr 参与的编译期计算。这些地方的 inline，使得你可以写出表达力极强的 C++ 代码，同时在生成的汇编层面，几乎和手写 C 没有区别。
这正是现代 C++ 在嵌入式领域最迷人的地方：抽象不是负担，而是可以被完全优化掉的语义工具。
在中断服务函数或极端热路径中，inline 也可能是合理的，但前提永远只有一个：你真的看过汇编，并且确认它解决了实际问题。