#error 与 #warning：编译时错误与警告、静态断言、版本检查
各位同学，今天我们来聊聊预处理指令里两个特别「有脾气」的家伙——#error 和 #warning。
说实话，我刚入行那会儿，觉得这两个指令没啥用。代码能跑就行，搞什么编译时检查？直到有一次，我在一个大型嵌入式项目里，因为头文件版本不匹配，整整调了三天才找到问题根源……嗯，从那以后，我再也不敢小看它们了。
一、#error：编译时的「急刹车」
#error 的作用很简单——让编译直接停下来，并输出你指定的错误信息。
你想想看，有些错误如果在编译阶段就能发现，何必等到运行时去头疼？
核心语法：
#error "错误描述信息"我在项目中遇到过最典型的场景：芯片选型时，某个外设驱动只支持特定系列的MCU。如果有人不小心把代码移植到不兼容的型号上，编译直接报错，比运行时崩溃友好一百倍。
#if !defined(STM32F4) && !defined(STM32F7)
#error "此驱动仅支持 STM32F4 和 STM32F7 系列！"
#endif你看，编译都过不了，问题自然就暴露了。
二、#warning：温柔的提醒
#warning 和 #error 类似，但它不会中断编译。它只是输出一条警告信息，编译继续。
我个人习惯用 #warning 来做「临时标记」或「待办提醒」。比如代码里有个临时方案，后续需要优化：
#warning "此处使用了临时DMA缓冲区，后续需改为动态分配"编译时看到这条警告，你就知道这里还有个坑没填。
小技巧： 我经常在调试阶段用 #warning 标记那些「我知道有问题但暂时不改」的地方。等代码稳定了，再统一清理这些警告。
三、静态断言：编译时的「体检报告」
说到静态断言，就不得不提 static_assert。它是 C11 标准引入的关键字，用于在编译时检查条件是否成立。
为什么需要它？
举个例子。我在做嵌入式底层驱动时，经常需要操作寄存器。如果结构体的大小或成员偏移量不符合预期，运行时就会出大问题。用 static_assert 可以在编译时就发现这些隐患。
#include <stddef.h>
typedef struct {
uint32_t CR; // 控制寄存器
uint32_t SR; // 状态寄存器
uint32_t DR; // 数据寄存器
} UART_Regs;
// 检查结构体大小是否符合硬件手册
static_assert(sizeof(UART_Regs) == 12, "UART寄存器结构体大小异常！");
// 检查成员偏移量
static_assert(offsetof(UART_Regs, SR) == 4, "SR寄存器偏移量错误！");编译时如果条件不满足，直接报错。这比运行时崩溃后拿着示波器抓波形，要高效得多。
注意： static_assert 的第二个参数是字符串字面量，不能是变量。这是 C 标准的规定。
四、版本检查：防止「水土不服」
嵌入式开发中，不同编译器、不同库版本之间的差异，经常让人头疼。
我曾经接手过一个项目，代码里用了 GCC 的某些扩展语法。结果同事用 IAR 编译，直接报一堆错。从那以后，我养成了在代码开头做版本检查的习惯。
#if defined(__GNUC__)
#if __GNUC__ < 8
#error "需要 GCC 8.0 或更高版本！"
#endif
#elif defined(__ICCARM__)
#if __ICCARM__ < 810
#warning "建议使用 IAR 8.10 以上版本"
#endif
#else
#error "不支持的编译器！"
#endif你看，这样一写，换编译器的人第一时间就能知道问题出在哪。
五、综合应用：一个完整的编译时检查框架
下面是我个人在项目中常用的一个编译时检查模板，供你参考：
/*
* 编译时检查框架
* 适用于嵌入式C项目
*/
// 1. 编译器版本检查
#if defined(__GNUC__)
#if __GNUC__ < 8
#error "GCC版本过低，请升级到8.0以上"
#endif
#elif defined(__ICCARM__)
#if __ICCARM__ < 810
#warning "IAR版本较低，部分功能可能受限"
#endif
#else
#warning "未识别的编译器，请自行验证兼容性"
#endif
// 2. 平台架构检查
#if !defined(__ARM_ARCH_7M__) && !defined(__ARM_ARCH_7EM__)
#error "此代码仅支持ARM Cortex-M3/M4/M7架构"
#endif
// 3. 关键数据类型大小检查
static_assert(sizeof(int) == 4, "int必须为32位");
static_assert(sizeof(short) == 2, "short必须为16位");
// 4. 对齐要求检查
typedef struct {
uint8_t a;
uint32_t b;
} __attribute__((packed)) PackedStruct;
static_assert(sizeof(PackedStruct) == 5, "打包结构体大小异常");核心思路： 把能放在编译时检查的，绝不留到运行时。编译器的检查能力，是你最廉价、最可靠的防御手段。
六、知识体系图
下面这张图，帮你理清本章的核心脉络：
七、避坑指南
最后，分享几个我踩过的坑：
- #error 不能放在函数内部——它是预处理指令，必须在文件作用域使用。
- #warning 不是标准C——它是大多数编译器支持的扩展。如果你写的是跨平台代码，要注意兼容性。
- static_assert 的条件必须是常量表达式——不能依赖运行时变量。
- 别滥用 #warning——我曾经在一个项目里加了十几个 #warning，结果编译时满屏黄色，真正的警告反而被淹没了。
我的习惯： 每个源文件开头做一次版本和平台检查，关键数据结构加 static_assert，临时方案用 #warning 标记。这样既保证了代码的健壮性，又不会让警告信息泛滥。
好了，关于编译时检查的内容就讲到这里。这些工具用好了，能让你的代码在编译阶段就「百毒不侵」。下次写代码时，不妨试试在关键位置加个 static_assert，你会发现——原来很多 bug 根本活不到运行时。