6、条件编译（#if, #ifdef, #ifndef）：条件编译的基本语法，调试开关与平台适配，头文件保护符（#pragma once vs #ifndef）

条件编译，说白了就是让编译器“挑着看代码”。

你写了一大堆代码，但有些部分只在调试时有用，有些只针对Windows，有些只针对Linux。怎么办？删掉？太蠢。注释掉？代码会变得乱七八糟。条件编译就是干这个的——它让预处理器在编译之前，决定哪些代码“留下来”，哪些“扔出去”。

我个人习惯把条件编译分成三类：开关控制、平台适配、头文件保护。咱们一个一个说。

6.1 基本语法：#if、#elif、#else、#endif

先看最基础的一组：#if、#elif、#else、#endif。它们跟C语言的if-else很像，但注意——它们是在编译阶段执行的，不是运行时。

#define DEBUG_LEVEL 2

#if DEBUG_LEVEL >= 3
    printf("详细调试信息\n");
#elif DEBUG_LEVEL >= 1
    printf("简要调试信息\n");
#else
    printf("无调试信息\n");
#endif

这里有个坑：#if后面跟的是常量表达式，不能是变量。你想想看，变量是运行时才有的东西，预处理器哪知道它是什么？

注意：#if 后面的表达式必须是整数常量表达式。不能写 #if (a > 0)，除非 a 是宏定义。

6.2 #ifdef 与 #ifndef：更常用的“存在性检查”

说实话，我在实际项目中用得最多的其实是 #ifdef 和 #ifndef。它们不关心宏的值是多少，只关心“这个宏有没有被定义”。

#ifdef FEATURE_ENABLE
    // 启用某个功能
    enable_feature();
#endif

#ifndef DISABLE_LOGGING
    log_message("系统启动");
#endif

我曾经在一个嵌入式项目里，用 #ifdef 控制了一大堆调试开关。产品发布时，只需要在编译命令行加一个 -DDISABLE_DEBUG，所有调试代码就全消失了。干净利落。

小技巧：可以用 #ifdef 配合 #undef 在代码中间临时取消宏定义，实现更细粒度的控制。

6.3 调试开关：让代码“隐身”的艺术

调试开关是条件编译最经典的应用场景。我见过很多新手直接在代码里写 printf，调试完了再一行行删。说实话，这太原始了。

更好的做法是这样：

// 调试开关定义
#define DEBUG_ENABLE     1
#define DEBUG_VERBOSE    0

#if DEBUG_ENABLE
    #define DEBUG_PRINT(fmt, ...) printf("[DEBUG] " fmt "\n", ##__VA_ARGS__)
#else
    #define DEBUG_PRINT(fmt, ...) // 空定义，编译时直接消失
#endif

void process_data(int *data, int len) {
    DEBUG_PRINT("处理数据，长度: %d", len);
    // ... 业务逻辑 ...
}

你看，发布时只要把 DEBUG_ENABLE 改成 0，所有调试打印就“人间蒸发”了。而且因为宏是空定义，编译器优化后连一条指令都不会多。

核心思想：调试代码和发布代码共存于同一个源文件，通过条件编译开关决定“谁上场”。既保留了调试能力，又不影响发布版本的性能。

6.4 平台适配：一套代码，多平台跑

做嵌入式的人都知道，换一个芯片平台，代码可能要大改。但有了条件编译，你可以把平台相关的代码“藏”在 #ifdef 后面。

// 平台检测宏，通常在编译器命令行或头文件中定义
// #define PLATFORM_STM32
// #define PLATFORM_ESP32
// #define PLATFORM_LINUX

#if defined(PLATFORM_STM32)
    #include "stm32f4xx.h"
    #define LED_PIN       GPIO_PIN_13
    #define LED_PORT      GPIOD
#elif defined(PLATFORM_ESP32)
    #include "esp32_gpio.h"
    #define LED_PIN       2
    #define LED_PORT      NULL
#elif defined(PLATFORM_LINUX)
    #include <stdio.h>
    #define LED_PIN       -1
    #define LED_PORT      NULL
#else
    #error "未定义平台，请选择 STM32、ESP32 或 Linux"
#endif

void led_init(void) {
#if defined(PLATFORM_STM32)
    HAL_GPIO_WritePin(LED_PORT, LED_PIN, GPIO_PIN_RESET);
#elif defined(PLATFORM_ESP32)
    gpio_set_direction(LED_PIN, GPIO_MODE_OUTPUT);
#elif defined(PLATFORM_LINUX)
    printf("模拟LED初始化\n");
#endif
}

嗯，这里要注意：#error 是个好东西。如果用户忘了定义平台宏，编译直接报错，比运行时崩溃友好多了。

我遇到过最头疼的情况是——不同平台的字节序不一样。用条件编译写了一套“大小端自适应”的代码，从此再也不用为数据格式发愁。

6.5 头文件保护符：#pragma once vs #ifndef

头文件保护符，说白了就是防止同一个头文件被包含多次。你想想看，如果 a.h 包含了 b.h，而 c.h 也包含了 b.h，然后你的源文件同时包含 a.h 和 c.h——没有保护符的话，b.h 的内容会被编译两次，轻则重复定义报错，重则编译崩溃。

两种主流做法：

方法 写法 优点 缺点
#ifndef 保护符 
#ifndef MY_HEADER_H
#define MY_HEADER_H
// ... 头文件内容 ...
#endif
 标准C语言支持，所有编译器都兼容 宏名可能冲突，需要手动保证唯一性
#pragma once 
#pragma once
// ... 头文件内容 ...
 写法简洁，编译器自动处理，不会冲突 非标准，极少数老编译器不支持

我个人习惯是：新项目用 #pragma once，因为简洁、省心。但如果是需要跨老平台的项目，或者要兼容某些“古董级”编译器，我会老老实实用 #ifndef。

避坑指南：我曾经在一个项目里看到有人把 #ifndef 的宏名写成了 _HEADER_H，结果跟系统头文件的宏冲突了，编译报了一堆莫名其妙的错。所以用 #ifndef 时，宏名一定要加项目前缀，比如 MYPROJ_HEADER_H。

另外，#pragma once 有个小陷阱：如果同一个头文件在文件系统中有多个副本（比如软链接、硬链接），某些编译器可能无法正确识别它们是同一个文件，导致保护失效。不过说实话，这种场景我工作十年也就遇到过一次。

6.6 知识体系总览

下面这张图把条件编译的核心知识点串起来了。你可以把它当作一个“速查地图”。

条件编译知识体系 条件编译 基本语法 调试开关 & 平台适配 头文件保护符 #if / #elif #else #endif #ifdef 调试开关 #ifndef 平台适配 #ifndef 保护 #pragma once 核心原则 编译前决定代码去留，不增加运行时开销 宏名命名要有项目前缀，避免冲突

条件编译这东西，用好了是神器，用不好就是灾难。我见过最夸张的一个项目，一个源文件里嵌套了七八层 #ifdef，代码完全没法读。所以我的建议是：能用函数抽象的就别用条件编译，条件编译只用来处理“编译时就能确定”的差异。

好了，这一章的内容就到这里。调试开关、平台适配、头文件保护——这三个场景基本覆盖了条件编译 90% 的用途。剩下的 10%，等你遇到具体问题时，再回来翻翻这张图就行。

← 上一章 📖 返回目录 下一章 →