C++条件编译是预处理阶段行为，非运行时判断；常见错误包括错写#ifdef DEBUG == 1、头文件卫士漏#define、平台宏误用及#if 0滥用；应优先用g++ -dM -E验证宏定义。
直接说结论：C++条件编译不是“运行时判断”，而是预处理器在编译前就裁掉代码——写错位置、漏写#endif、误把#ifdef DEBUG == 1当合法语法，这三处最容易导致静默错误或构建失败。
为什么#ifdef DEBUG不能写成#ifdef DEBUG == 1
#ifdef只检查宏是否被定义，不解析值、不支持表达式。它后面只能跟一个标识符（比如DEBUG），不能带==、&&或数字。
常见错误现象：#ifdef DEBUG == 1会被预处理器当作“检查宏DEBUG是否定义”+“剩下== 1作为普通代码”，结果可能编译报错，也可能意外通过但逻辑失控。
正确做法：
- 仅需存在性判断 → 用
#ifdef DEBUG或等价的#if defined(DEBUG) - 需要判断值（如
DEBUG被定义为2才启用）→ 必须用#if DEBUG > 0，但前提是DEBUG已定义为整数；更安全写法是#if defined(DEBUG) && DEBUG > 0 - 想同时检查多个宏 → 只能用
#if配合defined()，例如#if defined(WIN32) && defined(USE_OPENGL)
#ifndef最常用于头文件卫士，但容易漏掉#define
头文件卫士的标准写法是#ifndef HEADER_NAME_H → #define HEADER_NAME_H → #endif。漏掉中间那行#define，整个卫士就失效——头文件仍会被重复包含，引发重定义错误。
使用场景：所有公开头文件都应加卫士，尤其当你在utils.h里#include "config.h"，而别人又在main.cpp里同时#include "utils.h"和#include "config.h"时。
实操建议：
- 命名统一用大写下划线，如
#ifndef UTILS_H，避免和变量名冲突 - 不要依赖IDE自动生成的随机名（如
UTILS_H_123456789），它不利于手动维护和跨项目复用 - 如果头文件本身依赖其他头文件，卫士要包住
#include语句，否则起不到防重包含作用
跨平台判断别硬背_WIN32或__linux__，先查实际宏定义
不同编译器、构建系统、SDK版本对平台宏的支持差异很大。比如：__linux__在Android NDK默认不定义，_WIN32在MinGW下有，但WINDOWS这种自定义宏根本不存在于标准工具链中。
常见错误现象：本地Windows编译通过，CI上Linux构建失败，日志里只报“unknown platform”，找不到具体哪段#ifdef没覆盖到。
实操建议：
- 调试时优先运行
g++ -E empty.cpp（或cl /EP empty.cpp）查看预处理后输出，确认哪些宏真正在当前环境中生效 - 平台判断优先用组合：
#if defined(_WIN32) || defined(_WIN64)比单用#ifdef _WIN32更鲁棒 - 避免嵌套过深：不要写三层
#ifdef套#ifdef再套#ifdef，改用#if一次性写清条件，例如#if defined(__linux__) && !defined(ANDROID)
#if 0不是注释，是物理删除代码
#if 0和#endif之间的代码，连词法分析都不会进行——它不会触发宏展开、不检查语法、不报错，也不会占用任何目标文件空间。这点和/* ... */注释完全不同。
使用场景：临时屏蔽一大段尚未完成的代码，或保留旧逻辑但确保它绝对不出现在最终固件里（比如MCU项目中禁用全部printf）。
容易踩的坑：
- 编辑器可能不识别
#if 0块内的语法，导致高亮错乱或跳转失效，别靠它“隐藏”待修复的错误 - 如果块内有未闭合的
"、{或/*，预处理器照样吞掉，不会报错，但会干扰后续代码的结构理解 - CI构建时若开启
-Wundef，#if 0里的未定义宏也不会警告——它根本没被扫描
真正麻烦的从来不是语法记不住，而是宏从哪来：可能是CMake传入的-DDEBUG，可能是IDE设置里勾选的“Debug Mode”，也可能是某个第三方头文件悄悄#define了一个同名宏。遇到诡异行为，第一反应不是改代码，而是跑g++ -dM -E /dev/null | grep DEBUG看宏到底在哪冒出来的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
