宏定义的陷阱：#define SQUARE(x) x*x 为什么不对？
说实话，宏定义这个问题，我几乎每年都会在面试题里看到。很多刚入行的朋友觉得宏就是简单的文本替换，没什么好学的。但恰恰是这种轻视，让它在实际项目中频频翻车。
我记得有一次，团队里一个同事写了个计算平方的宏，测试单个数字时一切正常。结果放到一个复杂的控制算法里，输出值完全不对。排查了整整一个下午，最后发现就是宏展开时运算符优先级搞的鬼。嗯，从那以后，我对宏定义就格外小心了。
问题出在哪？
先看这个经典的错误写法：
#define SQUARE(x) x*x你可能会想，这有什么问题？SQUARE(5) 展开不就是 5*5 吗？结果确实是25，没错。
但换个场景试试：
int a = 3;
int result = SQUARE(a + 1);你期望的结果是多少？应该是 (3+1)*(3+1)=16 对吧？
实际展开后却是：
int result = a + 1 * a + 1;根据运算符优先级，乘法优先，所以实际计算的是：
int result = a + (1 * a) + 1; // 3 + 3 + 1 = 7结果变成了7，完全不是我们想要的16。为什么会这样？因为宏只是做纯粹的文本替换，它不会帮你加括号，也不会考虑运算优先级。
核心要点：宏展开是预处理阶段的文本替换，不是函数调用。它没有类型检查，没有作用域，也不会自动处理优先级。
还有更隐蔽的坑
你以为加个括号就完事了？再来看这个：
#define SQUARE(x) (x)*(x)好，现在 SQUARE(a+1) 展开成 (a+1)*(a+1)，结果对了。但如果你这样用呢：
int x = 2;
int result = SQUARE(++x);你期望的是 3*3=9，但实际展开后：
int result = (++x)*(++x);这里 ++x 被执行了两次！x 被自增了两次，最终 x 变成4，result 的值是 4*4=16。而且这个行为在C语言中是未定义的，不同编译器结果可能都不一样。
警告：永远不要在宏参数中使用自增、自减操作符（++、--），也不要使用带有副作用的表达式。宏参数会被多次展开，副作用也会被多次执行。
正确的写法是什么？
我个人习惯这样写：
#define SQUARE(x) ((x)*(x))外层再加一层括号，确保整个表达式作为一个整体。这样即使写在更大的表达式里，也不会出问题。
但说实话，对于这种简单的数学运算，我建议直接用内联函数：
static inline int square(int x) {
return x * x;
}内联函数有类型检查，参数只求值一次，没有宏的那些坑。现代编译器优化能力很强，内联函数的性能跟宏几乎没区别。
宏定义的正确使用场景
宏也不是一无是处。我在项目中主要用它做这几件事：
- 定义常量：
#define MAX_BUF_SIZE 1024 - 条件编译：
#ifdef DEBUG控制调试代码 - 通用工具宏：比如取两个数的最大值
说到取最大值，这也是个经典陷阱：
#define MAX(a, b) ((a) > (b) ? (a) : (b))这个写法比 SQUARE 好一些，但依然有副作用问题。比如 MAX(++x, y)，如果 ++x > y，那么 ++x 会被执行两次。
避坑指南：我曾经在代码审查时发现一个同事用宏实现了复杂的位操作，参数被展开了七八次。我建议他改成内联函数，不仅代码更清晰，调试时也能正常设置断点。宏虽然灵活，但过度使用会让代码变得难以维护。
宏与函数的对比
| 特性 | 宏 | 内联函数 |
|---|---|---|
| 类型检查 | 无 | 有 |
| 参数求值次数 | 每次展开都求值 | 只求值一次 |
| 调试支持 | 无法设置断点 | 可以设置断点 |
| 代码体积 | 每次使用都展开 | 编译器决定是否内联 |
| 适用场景 | 条件编译、简单常量 | 小型函数、类型安全 |
知识体系梳理
下面这张图总结了宏定义的核心陷阱和应对策略：
总结一下
宏定义本身不是恶魔，但用的时候要清楚它的本质——文本替换。记住三条原则：
- 参数和整个表达式都要加括号
- 不要在宏参数里放带副作用的表达式
- 能用内联函数就别用宏
你想想看，写代码是为了让人看懂，而不是为了炫技。宏虽然写起来很酷，但维护起来可能让人头疼。我现在的原则是：除非是条件编译或者定义常量，否则优先用内联函数。