6、#define 与 inline 函数：宏与内联函数的性能对比、使用场景选择
说到宏和内联函数，这其实是个老生常谈的话题了。但我发现很多工程师在实际项目中，要么一股脑全用宏，要么完全排斥宏只用 inline。这两种极端我都见过，结果都不太理想。
我个人习惯是：能不用宏的地方尽量不用，但该用宏的时候也别犹豫。听起来有点矛盾？别急，我们慢慢拆解。
6.1 宏的本质：文本替换的利与弊
宏说白了就是预处理器阶段的文本替换。你写了个 #define SQUARE(x) x*x，编译器看到 SQUARE(3) 就直接替换成 3*3。就这么简单，但也正因为简单，埋了不少坑。
宏的核心特点：
- 发生在编译之前，不参与类型检查
- 没有函数调用开销（压栈、跳转、返回）
- 每次使用都会展开，导致代码体积膨胀
- 参数会被多次求值，可能引发副作用
我在项目中遇到过这样一个经典问题：
#define MAX(a, b) ((a) > (b) ? (a) : (b))
int x = 5, y = 3;
int result = MAX(++x, y);
// 猜猜 result 是多少？x 又变成了多少？
展开后是 ((++x) > (y) ? (++x) : (y))，x 被自增了两次！结果 result 是 7，x 变成了 7。这跟预期完全不一样。嗯，这就是宏的典型陷阱——参数多次求值。
避坑指南：我曾经因为宏的参数副作用，在嵌入式电机控制代码里查了整整两天 bug。后来我养成了一个习惯：只要参数可能被多次求值，就坚决不用宏。
6.2 inline 函数：带类型检查的“伪宏”
inline 函数是 C99 引入的。它告诉编译器：这个函数调用时，尽量把函数体直接嵌入到调用点，别搞函数调用那一套。
但注意，inline 只是建议，不是命令。编译器可以忽略它。比如函数体太大、或者有递归调用，编译器可能就不内联了。
static inline int max(int a, int b) {
return a > b ? a : b;
}
int x = 5, y = 3;
int result = max(++x, y);
// 这里 ++x 只执行一次，result = 6，x = 6
看到了吗？同样的逻辑，inline 版本就安全多了。参数只求值一次，类型也检查了。你传个 float 进去，编译器会警告你。
6.3 性能对比：到底谁更快？
这个问题我经常被问到。说实话，在现代编译器优化面前，两者的性能差距已经微乎其微了。
我做过一个测试，在 ARM Cortex-M4 上，分别用宏和 inline 实现一个简单的饱和加法：
| 实现方式 | 代码大小（字节） | 执行周期 | 调用10次后代码膨胀 |
|---|---|---|---|
| 宏 | 12 | 3 | 120 |
| inline 函数（-O2） | 12 | 3 | 120 |
| 普通函数 | 8（函数体）+ 4（调用） | 7 | 48 |
有意思吧？在开启优化的情况下，宏和 inline 生成的代码几乎一模一样。但普通函数因为要压栈跳转，多了 4 个周期。
我的建议：别纠结那点性能差异。除非你是在写中断服务函数或者极端性能敏感的代码，否则 inline 函数完全够用，而且更安全。
6.4 使用场景选择：什么时候该用谁？
我总结了一套选择原则，这些年用下来挺顺手的：
优先用 inline 的场景
- 简单的 getter/setter：比如读取结构体成员，加个边界检查
- 类型安全的工具函数：max、min、clamp 这类
- 频繁调用的小函数：循环体内部调用的辅助函数
- 需要调试的代码：inline 函数可以设断点，宏不行
不得不用宏的场景
- 条件编译：
#ifdef DEBUG这种，inline 做不到 - 获取行号/文件名：
__LINE__、__FILE__只能在宏里用 - 生成重复代码：比如 X-Macro 技巧，批量定义结构体和枚举
- 实现泛型：C 语言没有模板，宏可以模拟
核心原则：能用 inline 解决的问题，就别用宏。宏只用来做那些 inline 做不到的事情。
6.5 一个实战案例：日志系统的选择
我之前写过一个嵌入式日志系统，就遇到了这个选择。需求是这样的：
- 日志要带文件名和行号
- 发布版本要能完全去掉日志代码
- 调试版本要尽可能快
你想想看，这个场景 inline 函数就搞不定了。因为 __LINE__ 在宏里才能正确展开。所以我用了宏 + inline 的组合：
// 日志宏，负责捕获行号和文件名
#define LOG_DEBUG(fmt, ...) \
do { \
if (g_log_level >= LOG_LEVEL_DEBUG) { \
log_write(__FILE__, __LINE__, LOG_LEVEL_DEBUG, fmt, ##__VA_ARGS__); \
} \
} while(0)
// 实际写入函数用 inline，减少调用开销
static inline void log_write(const char *file, int line, int level, const char *fmt, ...) {
// 格式化并写入缓冲区
// ...
}
这样既拿到了行号信息，又保证了性能。发布版本只需要 #define LOG_DEBUG(...) 为空宏，所有日志代码就消失了。
6.6 知识体系总览
下面这张图总结了宏和 inline 的核心区别与选择逻辑：
6.7 一些实用技巧
最后分享几个我这些年积累的小技巧：
- 宏的多语句包装：用
do { ... } while(0)包裹多语句宏，避免悬挂 else 问题 - inline 函数的 static 修饰：文件内使用的 inline 函数一定要加 static，否则链接时会报重复定义
- 调试宏的技巧：用
#pragma message("SQUARE macro expanded: " #x)查看宏展开结果 - 性能测量：别猜，用示波器或者 perf 工具实际测量。我见过太多人凭感觉优化，结果优化了个寂寞
最后提醒一句：不要为了“可能”的性能提升而牺牲代码的可读性和可维护性。你写的代码是给人看的，不是给编译器看的。编译器比你聪明多了。
好了，关于宏和 inline 函数的选择，就聊到这里。记住那个决策树，下次遇到类似问题，心里就有谱了。
公众号:蓝海资料掘金营，微信deep3321