宏不是函数，也不是变量，它是C语言编译前的文本替换工具，没有类型、没有作用域约束、不参与语法检查。这让宏既能简化代码，也能在预处理阶段悄悄篡改逻辑，成为无数隐蔽Bug的源头。
一、宏最基础的致命陷阱：括号缺失
宏只做无脑文本替换，不会自动处理运算优先级，少一个括号，结果天差地别。
#define SUM(a,b) a + b
int res = SUM(1,2) * 3;
展开后变成：1 + 2 * 3，结果为7，而非预期的9。
正确写法必须给整体和每个参数都加括号：
#define SUM(a,b) ((a) + (b))
二、参数多次展开引发的副作用灾难
当宏参数带有自增、函数调用等副作用时，多次引用参数会导致行为完全失控。
#define MAX(a,b) ((a) > (b) ? (a) : (b))
int x = 1;
int m = MAX(x++, 2);
展开后：((x++) > (2) ? (x++) : (2))
x 被自增两次，最终值完全不符合预期，这是函数永远不会出现的问题。
三、宏的分号陷阱：多写一个分号直接破坏语法结构
新手常习惯性给宏加分号，导致代码结构错乱。
#define SET_ZERO(x) x = 0;
if(1)
SET_ZERO(a);
else
a = 1;
展开后：
if(1)
a = 0;;
else
a = 1;
多余的分号让if语句提前结束，else失去匹配，直接编译报错。
安全写法：用do{...}while(0)包裹宏，杜绝分号问题。
四、宏无类型检查：比指针强转更危险
宏不关心参数类型，任何类型都能传入，编译器不会给出任何警告。
#define MUL(a,b) ((a)*(b))
int res = MUL("abc", 123);
代码依然会编译，最终运行出现乱码或崩溃，错误定位极其困难。
五、宏的作用域穿透：全局污染无法避免
宏在预处理阶段生效，无视函数、代码块作用域，一旦定义，整个文件后续都会受影响，极易出现命名冲突。
即使在函数内部定义宏，也会污染后续所有代码，直到#undef出现。
六、安全使用宏的五条铁律
- 所有宏表达式，整体与每个参数都必须加括号；
- 避免在宏内多次引用同一个参数，防止副作用爆炸；
- 多行宏统一用
do{...}while(0)包裹，兼容语句结构； - 能用
static内联函数替代的场景，坚决不用宏； - 宏定义后及时
#undef，缩小作用域，避免全局污染。
总结
宏的本质是文本替换，而非代码逻辑。它没有类型、没有栈、没有生命周期，所有看似方便的用法，背后都藏着预处理阶段的隐形篡改。
理解宏的底层替换规则，才能既用它简化代码，又避开那些藏在编译前的致命暗坑。
