条件编译发生在预处理阶段，决定哪些代码进入编译流程；条件判断发生在运行时，决定已编译代码中哪条分支被执行。前者裁剪源码、不生成目标码，后者所有分支均参与编译并占用二进制体积。
条件编译发生在编译前，条件判断发生在运行时；前者决定哪些代码进编译器，后者决定哪些语句被执行。
条件编译是预处理阶段的代码裁剪
预处理器扫描源文件时，遇到 #ifdef、#if、#ifndef 等指令，会直接丢弃不满足条件的代码块——这些代码根本不会传给编译器，也不会生成任何目标码。
这意味着：
- 被
#if 0包裹的代码，哪怕语法错误（比如少个括号、用了未声明的类型），也不会报错 - 宏定义必须在预处理时已知；
#if DEBUG_LEVEL > 2中的DEBUG_LEVEL必须是整型常量表达式（不能是变量或函数调用） - 头文件卫士（
#ifndef HEADER_H）靠的就是这个机制：重复包含时，第二次进来直接跳过整个内容
条件判断是编译后生成的运行时分支
if、switch 这类语句是 C++ 语言级结构，所有分支代码都会参与编译，最终生成汇编/机器码。程序运行到该处时才根据变量值跳转执行路径。
所以：
- 所有分支里的代码都必须语法正确、符号可解析（比如
if (flag) { use_unrelated_class(); }要求use_unrelated_class在作用域内声明） - 即使
if (false)，其内部代码仍占用二进制体积、可能触发静态初始化、甚至影响内联决策 - 无法绕过平台不兼容代码：比如在 Linux 编译时写
if (is_windows) { LoadLibrary(...); }，会直接链接失败——LoadLibrary根本不存在于 libc 中
#if 和 if 混用时容易踩的坑
新手常误以为 #if DEBUG 和 if (DEBUG) 可互换，但它们生命周期完全不同：
-
#define DEBUG 1+#if DEBUG：预处理时展开，DEBUG是字面量，不占运行时内存 -
const int DEBUG = 1;+if (DEBUG)：这是普通变量，哪怕值恒为 1，编译器也不保证能完全优化掉分支逻辑 - 更危险的是宏名拼写错误：
#ifdef DEUBG（少个 ‘G’）不会报错，但整段调试代码静默失效；而if (DEUBG)会直接编译失败 - 宏展开副作用：若
#define X() (i++)，#if X()会导致预处理器尝试把i++当作常量表达式计算，报错 “invalid integer constant expression”
什么时候该用哪个？看目标是否涉及“存在性”
选条件编译，当你要解决的问题本质是「这段代码能不能出现在当前构建中」：
- 跨平台 API 差异（
#ifdef _WIN32vs#ifdef __linux__） - 头文件防重入（
#ifndef MY_HEADER_H） - 发布版移除日志、断言、性能剖析钩子（
#ifndef NDEBUG）
选运行时判断，当你需要根据输入、状态、配置文件等动态信息做行为切换——这些值只有进程启动后才可知。
最易被忽略的一点：条件编译无法替代运行时策略。比如你用 #ifdef ENABLE_ENCRYPTION 编译出两个版本的程序，但用户实际是否启用加密，还得靠配置项或命令行参数控制——宏只管“有没有这段代码”，不管“要不要执行它”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
