ifdef在调试时经常失效，因其只识别字面量宏定义（如#define DEBUG），不展开运行时变量或表达式；必须通过编译器选项（-DDEBUG）或头文件显式定义，且仅接受宏名，不可跟赋值或逻辑运算。
为什么#ifdef在调试时经常失效？
因为预处理器只认字面量宏定义，不展开变量或表达式。#ifdef DEBUG不会识别const bool DEBUG = true;这种运行时变量——它只响应#define DEBUG或编译器传入的-DDEBUG。常见错误是把#ifdef当成if用，结果调试代码根本没编译进去。
- 必须用
#define DEBUG、#define _DEBUG等显式定义，或通过编译命令加-DDEBUG -
#ifdef后面不能跟赋值、函数调用或逻辑表达式，只接受宏名（如#ifdef ENABLE_LOG合法，#ifdef LOG_LEVEL > 2非法） - 宏定义作用域从定义点开始，到文件末尾或
#undef为止；跨文件需确保头文件包含顺序或统一在构建系统中定义
如何让#ifdef适配不同构建配置？
直接硬编码#define DEBUG在源码里会污染生产构建。正确做法是分离定义位置：开发时用构建系统注入，头文件只做条件判断。
- CMake中写
add_compile_definitions(DEBUG)或target_compile_definitions(myapp PRIVATE DEBUG) - Makefile中写
CXXFLAGS += -DDEBUG - 头文件里统一用
#ifdef DEBUG包裹日志、断言、性能计数器等调试逻辑，避免#ifdef __linux__这类平台宏和调试逻辑混在一起 - 推荐组合：
#ifdef DEBUG控制是否编译，#if DEBUG_LEVEL >= 2（配合#define DEBUG_LEVEL 1）控制粒度
#ifdef和#if在调试中怎么选？
#ifdef只检查宏是否存在，#if能做数值计算，但依赖宏已被定义为数字。调试中多数场景用#ifdef更安全。
- 检查开关状态（开/关）→ 用
#ifdef DEBUG，简洁且不易出错 - 区分调试等级（比如
DEBUG=0关闭，DEBUG=1基础日志，DEBUG=2全量dump）→ 用#if DEBUG >= 2，但要确保#define DEBUG 2已存在，否则#if DEBUG >= 2会被当作#if 0 >= 2 - 避免
#if defined(DEBUG) && DEBUG > 1这种写法——冗余且可读性差，直接#if DEBUG > 1更清晰（前提是DEBUG一定被定义）
调试代码残留导致Release崩溃怎么办？
最典型的坑是调试代码里用了未初始化指针、越界访问或依赖调试专用内存布局，而#ifdef DEBUG块在Release下被剔除，表面正常，实际掩盖了问题根源。
立即学习“C++免费学习笔记（深入）”；
- 所有
#ifdef DEBUG块内的代码仍需保证语法正确、不引入副作用（比如assert(ptr != nullptr)没问题，但ptr = new int[100]; delete[] ptr;在Release下消失，可能造成逻辑断裂） - 禁止在
#ifdef DEBUG里修改影响主逻辑的状态（如临时改全局标志、重置单例内部计数器） - 用
#ifndef NDEBUG替代#ifdef DEBUG更符合C++惯例——NDEBUG是标准断言控制宏，GCC/Clang/MSVC默认在-O2下定义它
宏不是万能开关，它删掉的是代码文本，不是设计缺陷。调试代码写得越“干净”，越不容易在切换配置时翻车。
