内联函数与宏：一场性能与安全的博弈
说到C语言的性能调优，内联函数和宏是绕不开的话题。我刚开始做嵌入式开发那会儿，总觉得宏是万能的——代码短、执行快、还没函数调用的开销。直到有一次，一个宏让我排查了整整两天的bug……嗯，从那以后我对宏的态度就谨慎多了。
inline关键字的使用
inline，说白了就是建议编译器：把这个函数的代码直接嵌入到调用处，别搞什么压栈出栈那一套。但注意，这只是「建议」，不是命令。编译器可以无视它。
// 典型的内联函数写法
static inline int max(int a, int b) {
return (a > b) ? a : b;
}我个人习惯在头文件里放这种小函数。为什么？因为内联函数的定义必须出现在每个调用它的编译单元里。放在头文件，省得重复声明。
什么时候用 inline？记住一条原则：函数体很小（通常 3-5 行），而且被频繁调用。比如 getter/setter、简单的比较函数、状态判断函数。你想想看，如果一个函数有几十行代码，内联后反而会让代码膨胀，指令缓存命中率下降，性能不升反降。
宏与内联的性能对比
宏和内联都能避免函数调用开销。但它们的性能表现，其实有细微差别。
| 对比维度 | 宏 | 内联函数 |
|---|---|---|
| 代码展开时机 | 预处理阶段 | 编译阶段 |
| 类型检查 | 无 | 有 |
| 参数求值次数 | 可能多次 | 一次 |
| 调试友好度 | 差 | 好 |
| 代码膨胀控制 | 不可控 | 编译器可优化 |
我在项目中遇到过这样一个场景：用宏实现一个平方计算，结果传入的是 x++，宏展开后变成了 (x++) * (x++)，x 被自增了两次。这就是宏的经典陷阱——参数被多次求值。
// 宏的陷阱示例
#define SQUARE(x) ((x) * (x))
int a = 5;
int b = SQUARE(a++); // 展开为 ((a++) * (a++))，a 被自增两次
// b 的结果是 30，而不是 25换成内联函数，这种问题根本不会出现。参数只求值一次，行为完全符合预期。
性能上，现代编译器对 inline 的处理已经非常智能。对于小函数，编译器会自动决定是否内联，甚至比手动 inline 效果更好。宏的优势其实在逐渐缩小。
何时该用内联
我总结了几条实战经验，供你参考：
- 函数体小于 5 行：比如简单的 getter、setter、状态判断
- 调用频率极高：比如在热循环中每秒调用百万次
- 需要类型安全：宏做不到的类型检查，内联函数可以
- 需要调试：内联函数可以设置断点，宏不行
那什么时候该用宏？说实话，现在能用内联的地方，我基本不用宏。宏唯一不可替代的场景是：
- 需要
__LINE__、__FILE__等预处理符号 - 需要生成代码片段（比如 X-Macro 技巧）
- 需要条件编译控制
核心观点： 能用内联就别用宏。内联函数更安全、更可读、更可调试。宏只保留给那些「非宏不可」的场景。
你想想看，代码是写给人看的，顺便给机器执行。宏的隐蔽问题太多，团队协作时很容易埋雷。我见过太多因为宏导致的诡异bug，排查起来让人抓狂。
最后说一句：不要迷信内联。编译器比你更懂什么时候该内联。先把代码写对，再用性能分析工具找热点，最后才考虑手动 inline 优化。顺序搞反了，你就是在瞎忙活。
我的建议： 团队协作时，在代码规范里明确禁止使用带副作用的宏。如果非要宏，必须加注释说明为什么不能用内联替代。我曾经在一个项目里推行这条规则后，宏相关的bug减少了80%。
记住，性能调优不是炫技。写出正确、可维护的代码，比追求那点微乎其微的性能提升重要得多。内联函数和宏的选择，本质上是在「性能」和「安全」之间找平衡。我个人倾向于安全优先——毕竟，跑得快的错误代码，比跑得慢的正确代码更可怕。