写这篇东西的起因，是我自己踩过的一个坑。前两年维护一个跨平台插件，需要在 Windows 上启用一个实验特性，在 Linux 上禁用。当时图省事，在头文件里写了个控制宏，然后按#if FLAG == 1走分支。编译倒是天天过，功能却始终没按预期生效。后来用预处理器输出一看，好家伙，宏展开之后根本不是我想的那样。从那次之后，我就把“判断宏的值是否为特定值”这件事从头捋了一遍——它看着简单，实际坑非常多。这篇文章就是那次复盘的结果，覆盖 C/C++ 里的经典宏判断、调试方法、跨平台场景，以及 Unity/C# 里宏判断的变体写法，适合正在写跨平台库、做模块裁剪或者被条件编译折腾过的开发者。
1. 预处理器视角：宏值判断为什么“只能这么想”
要真正搞懂怎么判断宏的值，先得把预处理器和编译器的分工弄明白。很多宏判断的问题，本质上是把预处理阶段的能力边界搞错了。
1.1 宏展开发生在哪一步：文本替换先于语法分析
C/C++ 编译过程的第一步是预处理，它做的是纯文本层面的替换和条件删除。#define定义的宏，在代码进入编译器（语法/语义分析）之前就已经全部展开完毕。这意味着：宏不存在“类型”，不存在“作用域”，只有“文本”。
这一点在宏值判断上非常关键。你在#if里写的一切，最终都会被翻译成对“整数常量表达式”的求值。举个例子：
#define MAX_SIZE 100 #if MAX_SIZE == 100 // 这段会被保留 #endif预处理器处理到#if时，先把MAX_SIZE替换成100，表达式变成100 == 100，结果为真，于是保留下面的代码。如果宏定义成(50 + 50)，同样成立，因为展开后是(50 + 50) == 100。
但如果你试图在#if里用变量：
int x = 100; #if x == 100 // 错误！ #endif这行代码预处理器直接报错。因为x不是宏，预处理阶段根本没有“变量”这个概念。这个道理听起来简单，但我在代码评审里见过太多次把const常量拿来跟宏比较的写法，编译不过了才意识到问题。
1.2 未定义宏在#if中默认是0，这是便利更是陷阱
这是宏判断中最容易翻车的规则之一：在一个#if表达式中，如果某个标识符不是宏，也没有被defined操作符包裹，那么它会被替换成0，然后参与表达式求值。
#if UNDEFINED_MACRO == 0 #error "居然走进了这里？" #endif上面这段代码不会报错，因为UNDEFINED_MACRO从未定义，预处理器把整个表达式理解为0 == 0，结果是真，整段代码会被保留。如果里面放的是实际业务代码，后果就是：你以为这个宏没定义就不会编译，实际上它不但编译了，还执行了。
这个规则在 GCC、Clang、MSVC 里基本一致，属于标准行为。问题在于，编译器会把这个“宏未定义被替换为0”当成一种需要提醒的用法，GCC 会给出-Wundef警告，但默认不开启。你可以在项目的编译参数里加上它，把潜在问题暴露出来。
所以我在项目里定了一条规矩：凡是可能未定义的宏，在#if里参与比较之前，必须先用defined确认。直接裸写#if FOO == 1，等同于假设“未定义时按0处理”，这在大部分场景下不是你要的语义。
1.3 #if表达式只认识整型常量，不认识变量和类型
除了未定义宏当作0，#if还有很多边界限制：
- 不能使用
sizeof，因为尺寸计算发生在编译阶段，预处理器不知道类型布局。 - 不能使用浮点字面量，
#if 1.5 == 1直接报错。 - 不能使用强制类型转换。
- 不能使用字符串字面量。
- 可以使用字符常量，比如
#if CH == 'A'，这是合法的，因为字符常量本质是个整数。
实际项目中，我遇到最多的就是有人想把浮点版本号写进宏里比较。比如#define APP_VERSION 2.1，然后#if APP_VERSION >= 2.1。这在预处理阶段完全不可行，因为2.1不是合法的整数常量表达式。解决方案是把版本号拆成整数部分和小数部分，或者用一个放大后的整数表示，例如#define APP_VERSION_MAJOR 2、#define APP_VERSION_MINOR 1，再组合成(MAJOR * 100 + MINOR)来比较。
2. 判断宏是否为特定值：三种写法的选型与纠错
铺垫完底层规则，具体谈谈怎么写。判断宏的值，看起来只需要#if MACRO == VALUE，但实际操作中有三种不同力度的判断，它们对应不同场景。
2.1 只判断定义：#ifdef能做什么，不能做什么
#ifdef MACRO（等价写法是#if defined(MACRO)）只回答一个问题：这个宏有没有被定义。它不关心宏展开之后是什么内容，哪怕宏被定义为空，#ifdef也认为是“已定义”。
#define FEATURE_A // 空定义 #ifdef FEATURE_A // 会被编译 #endif这种写法适合“开关型”宏：你只关心这个功能开关是否打开，不关心它的具体级别或数值。C 标准库里的NDEBUG、_WIN32这类宏，基本都是按这个思路用的。
但要注意它的局限：如果阈值有多个档位，比如日志分为 DEBUG、INFO、WARN、ERROR，只用#ifdef表达不了“当前级别是否大于等于 WARN”。这时候需要引入数值宏，直接比较大小。
2.2 判断宏值等于某个数：#if MACRO == N的模式与坑
数值宏是判断宏值最直接的方式：
#define LOG_LEVEL 2 #if LOG_LEVEL == 2 // 启用 WARN 及以上日志 #endif这个写法有两个典型陷阱。
第一个陷阱是未定义宏会当作0。如果某个编译单元没有引入定义LOG_LEVEL的头文件，#if LOG_LEVEL == 2会静默变成0 == 2，结果是假，代码被排除，但编译器不会报错。排查起来很费时间。
第二个陷阱是宏自身展开后可能破坏表达式。比如：
#define FLAGS 1 | 4 #if FLAGS == 5 // 预期进入，实际不会进入 #endif为什么？因为宏展开后表达式变成1 | 4 == 5。运算符优先级里==高于|，所以这行实际是1 | (4 == 5)，即1 | 0，结果等于1，永远不等于5的真值。这就是我在开头说的那个坑的根源之一——宏定义不写括号，在#if条件里遇到二元运算符时，整个逻辑就乱了。
2.3 需要同时匹配“已定义”和“特定值”时怎么组合
最稳妥的写法是把defined检查和值比较组合起来：
#if defined(LOG_LEVEL) && LOG_LEVEL == 2 // 只有 LOG_LEVEL 被定义，并且值恰好等于 2 时才进入 #endif这写法利用了&&的短路规则：如果宏未定义，左侧defined(LOG_LEVEL)为假，右侧根本没有机会参与求值，也就避开了“未定义宏当作0”的干扰。
对于多值判断，可以用#elif链：
#if defined(LOG_LEVEL) && LOG_LEVEL == 0 #elif defined(LOG_LEVEL) && LOG_LEVEL == 1 #elif defined(LOG_LEVEL) && LOG_LEVEL == 2 #else #endif坦白说，这个写法比较啰嗦。更干净的做法是在头文件里统一做“归一化”处理：先判断是否定义，没定义就给个默认值，后面用#if LOG_LEVEL >= 2直接比较。
#ifndef LOG_LEVEL #define LOG_LEVEL 1 #endif #if LOG_LEVEL >= 2 // WARN及以上 #endif这样既避免了未定义宏的歧义，又让后续判断精简。这是我在项目里最常用的模式。
2.4 字符串宏的值判断：预处理期做不到，但有替代方案
前面说过，#if里不能放字符串字面量。那如果宏定义的是一个字符串，比如#define APP_ENV "prod"，该怎么判断它的值？
答案是：在纯预处理阶段，没有办法直接做字符串相等比较。这是 C/C++ 预处理器的能力边界，不要硬刚。
但有几种绕行方案。最实用的是给字符串宏映射一个编号：
#define ENV_UNKNOWN 0 #define ENV_DEV 1 #define ENV_PROD 2 #ifndef APP_ENV_ID #define APP_ENV_ID ENV_UNKNOWN #endif #if APP_ENV_ID == ENV_PROD // 生产环境专有逻辑 #endif在构建脚本里，-DAPP_ENV_ID=2之类的参数控制，比直接传字符串可靠得多。
如果在 C++17 及以上的代码里，还可以借助constexpr函数把判断放到编译期：
#include <string_view> #ifndef APP_ENV #define APP_ENV "dev" #endif constexpr bool IsProd() { return std::string_view(APP_ENV) == "prod"; } // 用法 static_assert(!IsProd(), "生产环境不应该开启这个文件");这种方式已经脱离预处理器的范畴，但它确实解决了“根据宏字符串值做编译/运行期分支”的需求。实际项目里如果允许使用 C++17，我倾向用这个方案替代掉一批复杂的宏判断。
3. 实战：版本号、平台与特性开关的宏判断布局
说完了语法层面的选择，接下来看真实项目里宏值判断最常出现的三个地方：版本判断、平台识别和特性开关。
3.1 版本号宏：比较大小、组合版本信息
版本判断是宏值比较最典型的应用。比如一个库对外提供版本宏：
#define MYLIB_VERSION_MAJOR 2 #define MYLIB_VERSION_MINOR 6 #define MYLIB_VERSION_PATCH 3使用方要判断“主版本大于等于2，或者主版本等于2且次版本大于等于6”，可以这样写：
#if MYLIB_VERSION_MAJOR > 2 || \ (MYLIB_VERSION_MAJOR == 2 && MYLIB_VERSION_MINOR >= 6) // 使用较新的API #else // 退回到兼容实现 #endif项目里更常见的做法是合成一个递增的版本号，直接比较大小：
#define MYLIB_VERSION (MYLIB_VERSION_MAJOR * 10000 + \ MYLIB_VERSION_MINOR * 100 + \ MYLIB_VERSION_PATCH) #if MYLIB_VERSION >= 20603 // 2.6.3 及以上版本 #endif注意这里必须给整个版本表达式套上括号。我见过项目里这么写的：#define MYLIB_VERSION MYLIB_VERSION_MAJOR * 10000 + MYLIB_VERSION_MINOR * 100 + MYLIB_VERSION_PATCH，然后在别的宏判断里跟其他运算组合，展开之后优先级乱成一团，出过好几次问题。版本宏这种会被到处引用的常量，括号是无条件要加的。
3.2 平台与编译器识别宏的判断套路
跨平台代码里，平台识别宏是另一类高频判断对象。这类宏通常由编译器预定义，值可能为1，也可能只定义不赋值，还有的干脆是版本号。
典型的组合判断：
#if defined(_WIN32) #define PLATFORM_WINDOWS 1 #elif defined(__APPLE__) #include <TargetConditionals.h> #if TARGET_OS_IPHONE #define PLATFORM_IOS 1 #else #define PLATFORM_MACOS 1 #endif #elif defined(__linux__) #define PLATFORM_LINUX 1 #else #error "Unknown platform" #endif这段代码里有一个很重要的细节：_WIN32和__linux__这类宏本身不带数值语义，用#if defined(...)判断就够了。而 Apple 的TARGET_OS_IPHONE是带值的，且要求引入TargetConditionals.h头文件才能看到定义，所以必须先包含头文件，再用#if TARGET_OS_IPHONE判断值是否等于1。
编译器识别同样常见：
#if defined(__clang__) #define COMPILER_CLANG 1 #elif defined(__GNUC__) #define COMPILER_GCC 1 #elif defined(_MSC_VER) #define COMPILER_MSVC 1 #endif还有一个容易踩的坑：__GNUC__和__clang__会同时存在，因为 Clang 也定义了不少__GNUC__前缀的兼容宏。所以判断顺序必须是先判断 Clang，再判断 GCC，否则会被误识别。这是我在真实项目中遇到过的。
3.3 特性开关宏：从-D传入到#if消费的完整链路
特性开关宏经常来自构建系统。以 CMake 为例：
option(ENABLE_EXPERIMENTAL "Enable experimental feature" OFF) target_compile_definitions(myapp PRIVATE EXPERIMENTAL_MODE=$<IF:$<BOOL:${ENABLE_EXPERIMENTAL}>,1,0>)传给编译器的实际参数是-DEXPERIMENTAL_MODE=1或-DEXPERIMENTAL_MODE=0。在代码里，我习惯用“未定义默认0”的策略：
#ifndef EXPERIMENTAL_MODE #define EXPERIMENTAL_MODE 0 #endif #if EXPERIMENTAL_MODE == 1 // 实验特性代码 #endif这里为什么先用#ifndef给默认值，而不是直接裸写#if EXPERIMENTAL_MODE == 1？区别在于：如果某个编译单元忘了通过构建系统传这个宏，裸写会按0处理，看起来功能“关掉了”，但没有任何提示；而先#ifndef再定义默认值，至少明确表达了意图。
更好的做法是在不符合预期时直接发出编译期提示或错误：
#if !defined(EXPERIMENTAL_MODE) #error "EXPERIMENTAL_MODE must be defined as 0 or 1" #endif这个做法适合那些必须显式配置的开关，避免“没配置就当默认值”掩盖配置错误。
3.4 用#pragma message在编译期输出宏值确认结果
宏值判断不生效时，最直接的手段是在预处理期把宏值打印出来。C99 以来的标准做法是配合字符串化操作符#：
#define STRINGIFY_IMPL(x) #x #define STRINGIFY(x) STRINGIFY_IMPL(x) #pragma message("EXPERIMENTAL_MODE = " STRINGIFY(EXPERIMENTAL_MODE))这段代码放在头文件里，每次编译都会输出类似：
note: #pragma message: EXPERIMENTAL_MODE = 1我经常用它来验证“头文件里的宏到底生效没有”，比肉眼找代码快得多。MSVC 下也可以用#pragma message，GCC/Clang 则支持#warning，可以做到不符合预期时产生告警：
#if EXPERIMENTAL_MODE == 1 #warning "Experimental mode is enabled" #endif这些都是成本极低但效果非常好的排查手段。
4. 追击实录：一次宏判断不生效的完整排查过程
这部分我用自己的实际案例展开。整个过程值得完整记录，因为它代表了一种可复用的排查思路。
4.1 现象：同一个头文件，Debug和Release行为不一致
当时的情况是这样的：一个网络库里面有套重连逻辑，我希望在调试版本里把重试间隔从5秒缩短到1秒，于是设计了一个控制宏。
相关代码简化如下：
// config.h #ifndef RETRY_INTERVAL_SEC #define RETRY_INTERVAL_SEC 5 #endif #if RETRY_INTERVAL_SEC == 1 #define USE_SHORT_RETRY 1 #else #define USE_SHORT_RETRY 0 #endif构建系统里，Debug 配置传-DRETRY_INTERVAL_SEC=1，Release 配置传-DRETRY_INTERVAL_SEC=5。
问题出现了：Debug 版本的行为还是5秒重试。也就是说USE_SHORT_RETRY没有变成预期的1。最诡异的是，预处理指令没有报错，代码也正常编译运行，只是走进了我不想要的分支。
4.2 看预处理输出：gcc -E还原真相
宏判断这种“不报错但结果不对”的问题，最有效的排查手段是直接看预处理之后的产物。
GCC/Clang 下执行：
gcc -E -dD -I. config.c -o config_preprocessed.i关键参数-E表示只做预处理，-dD会保留所有宏定义，这样能同时看到宏“被定义的值”和“展开后的代码”。打开生成的文件，我看到了这样的内容：
#define RETRY_INTERVAL_SEC 1定义没问题，值确实是1。继续往下找条件编译区域，却发现预处理文件里那部分代码没有保留USE_SHORT_RETRY 1的定义，而是走了#else分支。也就是说，#if RETRY_INTERVAL_SEC == 1这个判断在预处理器眼里是假的。
到这里我基本锁定了问题不在宏的值，而在判断表达式本身。
4.3 根因：宏定义中丢了括号，运算符优先级背刺
我把注意力放回config.h的宏定义。往下翻发现，构建脚本里又传了一个宏，它和重试间隔产生了联动：
#define RETRY_BASE_SEC (RETRY_INTERVAL_SEC + 2)问题不在这。继续看，真正的元凶在另一个头文件里，它的写法是这样的：
#define DEFAULT_RETRY RETRY_INTERVAL_SEC + 2 #define USE_DEFAULT_RETRY_LIMIT (DEFAULT_RETRY > 3 ? 1 : 0)这里DEFAULT_RETRY展开为RETRY_INTERVAL_SEC + 2，再代入USE_DEFAULT_RETRY_LIMIT，得到：
(RETRY_INTERVAL_SEC + 2 > 3 ? 1 : 0)预处理表达式里运算符优先级决定一切，而+的优先级高于>，所以判断变成“当前值加2是否大于3，且整表达式进入三元操作”。当RETRY_INTERVAL_SEC为1时，1 + 2 > 3为假，结果是0。这和我预期的“重试间隔缩短到1秒”完全不在一个频道上。
其实更隐蔽的是，我原本的RETRY_INTERVAL_SEC == 1判断本身没被这个宏影响，它判断结果是真。但USE_SHORT_RETRY最终没有被使用到重试逻辑里，实际生效的是USE_DEFAULT_RETRY_LIMIT。也就是说，宏 A 的值判断对了，宏 B 却在组合时炸了。这就是为什么“看似正常的宏，展开后完全变了样”。
4.4 修复与防御：加括号只是第一步，static_assert兜底
修复很简单，所有带运算的宏定义一律加括号：
#define DEFAULT_RETRY (RETRY_INTERVAL_SEC + 2) #define USE_DEFAULT_RETRY_LIMIT ((DEFAULT_RETRY) > 3 ? 1 : 0)加括号后，展开结果符合直觉，重试逻辑也恢复正常。
但这个事故之后我给自己定了两条防御规则。第一条，宏定义里只要包含运算符，整个宏体必须用括号包裹，参数引用也必须用括号。第二条，在关键开关上使用编译期断言，让“判断结果不符合预期”在编译时直接暴露。
例如：
#include <assert.h> #define USE_SHORT_RETRY 1 _Static_assert(USE_SHORT_RETRY == 1, "USE_SHORT_RETRY must be 1");C11 里_Static_assert可以在编译期校验整数常量表达式；C++ 里对应static_assert。如果未来有人改动了宏定义导致判断结果变化，编译会在这里停下来，而不是带着错误的宏值继续跑下去。
5. Unity里的宏判断：从C语言迁移到C#后的差异
热搜词里“unity宏定义”出现频率很高，确实很多做游戏开发的同事会在 Unity 场景下遇到类似需求。Unity 的宏判断逻辑跟 C/C++ 同源，但有几个明显的差异。
5.1 Scripting Define Symbols：Unity版的编译期宏
Unity 引擎用一套叫“Scripting Define Symbols”的机制，在编译 C# 脚本之前向编译器注入符号。这一系列符号用分号分隔，在 Player Settings 的 Scripting Define Symbols 输入框里配置：
UNITY_IOS;UNITY_ANDROID;ENABLE_DEBUG_LOG也可以根据当前的 Build Target Group，用脚本批量设置。它和 C/C++ 预处理器宏的最主要区别是：Unity 的 Define Symbols 只能声明“符号”，不能赋“值”。也就是说，你不能写RETRY_INTERVAL_SEC=5然后让 C# 代码里用#if RETRY_INTERVAL_SEC == 5判断，只能写RETRY_INTERVAL_SEC用于#if defined(RETRY_INTERVAL_SEC)。
这一点直接影响“判断宏值是否为特定值”的写法。Unity C# 里只有两种选择：判断符号是否存在，以及通过布尔运算组合多个符号。
5.2 用#if判断平台符号和自定义符号
Unity 提供了一批内置平台符号，比较常见的有：
| 符号 | 含义 |
|---|---|
UNITY_EDITOR | 在编辑器环境下 |
UNITY_IOS | 目标平台为 iOS |
UNITY_ANDROID | 目标平台为 Android |
UNITY_STANDALONE_WIN | 目标平台为 Windows 独立程序 |
DEVELOPMENT_BUILD | 开发构建 |
典型判断写法：
#if UNITY_ANDROID && !UNITY_EDITOR // 只在真机 Android 生效的逻辑 #elif UNITY_IOS && !UNITY_EDITOR // 只在真机 iOS 生效的逻辑 #else // 编辑器或者其他平台 #endif这里要注意优先级和括号的使用。#if表达式里&&、||、!都是支持的，但建议显式带括号，避免阅读歧义：
#if (UNITY_ANDROID || UNITY_IOS) && !UNITY_EDITOR自定义符号的判断同理。在 Player Settings 里加了一个DEBUG_LOG_ENABLED后，代码里：
#if DEBUG_LOG_ENABLED Debug.Log("debug message"); #endif这属于“只判断定义”。由于 Unity 的符号系统不支持赋值，拿它去比较== 1是没有意义的，会直接编译报错。
5.3 “宏定义数组”的真正解法：批量设置与读取Define Symbols
搜索引擎里能看到“宏定义数组”这个热搜，在 Unity 语境下，它通常指的不是 C 语言里那种宏，而是“一组 Define Symbols”。比如按渠道设置多个符号：渠道 A 要PACKAGE_A; ANALYTICS_ON; TEST_SERVER，渠道 B 要PACKAGE_B; ANALYTICS_ON; PROD_SERVER。
这组符号在 Unity 的PlayerSettingsAPI 里就是字符串，读取和设置可以用以下方式：
using UnityEditor; using System.Collections.Generic; public static class DefineSymbolsHelper { public static void SetDefineSymbols(BuildTargetGroup group, List<string> symbols) { string combined = string.Join(";", symbols); PlayerSettings.SetScriptingDefineSymbolsForGroup(group, combined); } public static List<string> GetDefineSymbols(BuildTargetGroup group) { string combined = PlayerSettings.GetScriptingDefineSymbolsForGroup(group); return new List<string>(combined.Split(';')); } }把符号列表转成数组再处理，这就是“宏定义数组”的一种实际解法。你可以在自定义菜单里批量切换“开发服/正式服”符号组：
[MenuItem("Build/Use Test Server")] public static void SwitchToTestServer() { SetDefineSymbols(BuildTargetGroup.Android, new List<string> { "ANALYTICS_ON", "TEST_SERVER" }); }这样代码里就可以根据TEST_SERVER是否存在，决定连接到哪台服务器。虽然没有“宏值”的概念，但“判断这一组宏是否包含目标宏”的需求完全可以用#if TEST_SERVER && ANALYTICS_ON这种组合满足。
5.4 C#预处理指令的边界：只有定义判断，没有值判断
C# 的预处理指令整体比 C/C++ 更“薄”。可用的指令如下：
#define/#undef：只能在文件顶部声明符号，且只作用于当前文件，不能跨文件生效。#if/#elif/#else/#endif：分支判断。#warning/#error：输出编译期警告或错误。#region：代码折叠。#nullable：控制可空上下文。
关键限制是：#define后面只能跟一个符号名，不能带值。所以 C# 里天然没有“宏值等于特定值”的语法。需要“值”时，要么用枚举加构建脚本生成常量，要么用const字段：
public static class BuildConfig { public const int RetryIntervalSec = 5; } if (BuildConfig.RetryIntervalSec == 1) { // 运行时逻辑 }这种方式虽然不在预处理阶段生效，但结合常量内联，实际运行效果和宏比较非常接近。说到底，Unity C# 场景下的最佳实践是把“符号判断”用于平台/渠道分流，把“数值比较”交给运行时常量。
6. 宏判断的边界玩法：空宏、布尔化与调试工具
最后补充几个宏判断里偏进阶的技巧和边界情况，都是实际可能会用到的。
6.1 怎么判断一个宏“存在但值为空”
有些场景需要区分“宏未定义”和“宏被定义为空”。比如构建系统传入了-DFEATURE_FLAG（没有值），这跟没定义FEATURE_FLAG是两个状态。
#ifdef无法区分这两种状态，因为它只关心宏是否存在。#if FEATURE_FLAG == 1也不能用：空宏展开后，表达式变成#if == 1，直接语法错误。
预处理领域有一个经典的“探测”技巧，利用参数个数变化来判定宏是否为空：
#define PROBE(...) PUT_ ## __VA_ARGS__ #define CHECK_N(x, n, ...) n #define CHECK_N_WRAP(...) CHECK_N(__VA_ARGS__, 0,) #define IS_EMPTY(macro) CHECK_N_WRAP(PROBE(macro), 0,) #define PUT_0 1 #define PUT_0, 1, 1 0 // 这里的细节展开比较复杂，实际使用要仔细测试这个宏涉及可变参数宏、粘贴操作符和延迟展开，极其绕，而且不同编译器下的行为略有差异。我建议非必要不要在生产代码里使用。如果真需要区分空宏和未定义宏，更稳妥的方式是让构建系统统一用“带值宏”，比如-DFEATURE_FLAG=1，然后用#if defined(FEATURE_FLAG) && FEATURE_FLAG == 1判断。
6.2 宏退化与布尔判断的等价写法
有些代码喜欢把宏定义成布尔语义：
#define ENABLE_FEATURE 1判断时写：
#if ENABLE_FEATURE这等价于#if ENABLE_FEATURE != 0，对于取值只有0和1的宏来说没问题。但隐患是：如果有人把宏改成#define ENABLE_FEATURE (1 << 3)这种位域写法，#if ENABLE_FEATURE依然为真，但如果哪天宏定义变成#define ENABLE_FEATURE !0，展开后是!0，同样没问题。真正的问题是宏值出现负数或特殊表达式时，裸写#if MACRO的可读性和语义清晰度都不如实写“与特定值比较”。
我个人的习惯是：目标值明确时，一律写成#if MACRO == 1；只关心真假时，用#if MACRO也很自然，但要确保宏的来源可控。这个偏好没有绝对对错，核心是“团队内统一写法和规范”。
6.3 预处理表达式禁区与最后一道防线#error
预处理表达式里还有一些容易被忽略的禁区。比如：
#if defined(MACRO) && (MACRO & 0xFF00)位运算本身没问题，但宏展开要保证&优先级符合预期，否则需要加括号。再比如：
#if defined(A) == defined(B)两个defined的结果可以比较，这在某些配置一致性检查里非常有用，但要注意加括号换行，否则可读性很差。
还有一个高频踩坑：想在#if里判断枚举值。比如：
typedef enum { RED = 0, GREEN = 1 } Color; #if GREEN == 1 // 错误：GREEN 不是宏编译直接报错“token is not valid in preprocessor expressions”。解决方式只能是额外定义同名宏：
#define RED 0 #define GREEN 1 typedef enum { RED = RED, GREEN = GREEN } Color;这样既保留了枚举类型，又能在预处理期用宏判断。头文件里的上下文不同，这个技巧不一定适合所有项目，但在部分 C 工程里确实能解决实际问题。
最后谈一下#error。它是我在宏判断上最依赖的防御手段之一。当某个宏的条件组合不应该出现时，直接让编译停下：
#if defined(USE_SSL) && defined(USE_LWIP) #error "USE_SSL and USE_LWIP cannot be enabled at the same time" #endif这个比任何运行时检查都早，而且强制所有开发者面对问题，而不是等到产品上线后才发现配置冲突。宏判断的目的本来就是在编译期把决策确定下来，那么用#error亮明边界，就是这套体系最可靠的一部分。
回到开头那个问题：宏值判断本身不复杂，复杂的是宏在各个头文件、构建系统、平台定义之间的交互。我现在的习惯是先确认“宏从哪来、有没有定义、展开后长什么样”，再讨论用哪种写法判断。优先defined+ 括号完整的整型表达式，关键路径上用#pragma message或#error做编译期反馈，再配合-E看展开结果，这套流程基本能解决九成以上的宏判断疑难问题。希望这篇足够把你从类似的坑里捞出来。
