DEBUG宏不生效是因为定义位置错误，必须在所有#include之前定义，否则头文件已预处理完毕；应通过编译器参数-DDEBUG或源文件顶部#define定义，并用do{...}while(0)包裹多语句宏。
为什么 DEBUG 宏不生效？检查预处理器定义顺序
宏是否起作用，根本不在代码写得对不对，而在它有没有被真正“看见”。DEBUG 这类调试宏必须在任何 #include 之前定义，否则头文件里已经走完预处理流程了，再定义就晚了。
常见错误现象：printf("DEBUG: %d\n", x); 在 Release 下仍输出，或 #ifdef DEBUG 块完全没编译。
- 在源文件最顶部（早于所有
#include）加#define DEBUG - 更稳妥的做法是通过编译器参数传入：
g++ -DDEBUG main.cpp或 CMake 中用add_compile_definitions(DEBUG) - 不要在头文件里
#define DEBUG后再#include其他头——这会导致部分头看不到该宏
do { ... } while(0) 包裹宏体不是炫技，是防缩进和分号误用
直接写 #define LOG(x) printf("LOG: %s = %d\n", #x, x) 看似简单，但一旦放进 if 分支，就会因缺少大括号导致逻辑错乱。
使用场景：所有含多语句、需保持原子性的调试宏，比如打印 + 断言 + 计数。
立即学习“C++免费学习笔记（深入）”；
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
- 错误写法：
#define DEBUG_PRINT(x) printf("DBG: %d\n", x); fflush(stdout);—— 在if (flag) DEBUG_PRINT(val); else ...中，else会绑定到第二条语句 - 正确写法：
#define DEBUG_PRINT(x) do { printf("DBG: %d\n", x); fflush(stdout); } while(0) - 这个结构让宏在语法上等价于单条语句，
;不会引发歧义，也兼容if/for等上下文
用 __FILE__ 和 __LINE__ 定位问题，但注意宏展开后路径可能冗长
调试时最烦的是看到日志却不知道哪行触发的。__FILE__ 和 __LINE__ 是预处理器内置标识符，展开为字面字符串和整数，无需运行时开销。
性能影响几乎为零，但要注意 Windows 下 __FILE__ 可能带完整绝对路径，日志体积陡增。
- 推荐写法：
#define DEBUG_LOG(msg) do { fprintf(stderr, "[%s:%d] %s\n", __FILE__, __LINE__, msg); } while(0) - 如需裁剪路径，可用自定义宏（如
STRIP_PATH(__FILE__)），但会增加复杂度；更实际的做法是在构建时用-fmacro-prefix-map（GCC/Clang）统一替换前缀 - 避免在发布版中残留未屏蔽的
__FILE__日志——它们不会被#ifdef DEBUG自动包裹，必须显式控制
#pragma once 和 #ifndef 都能防重复包含，但调试宏依赖后者才能跨文件生效
你在一个 debug.h 里定义了 DEBUG_PRINT，但在另一个源文件里用不了？大概率是头文件没被正确定义或包含方式冲突。
#pragma once 虽简洁，但它是编译器扩展，不参与宏定义传播；而 #ifndef 防护块里的内容，在首次包含时才真正进入预处理上下文。
- 确保
debug.h使用传统卫士：#ifndef DEBUG_H/#define DEBUG_H/#endif，而不是仅靠#pragma once - 如果多个头都定义同名宏（比如都定义
LOG），且没用卫士保护，会出现重定义警告甚至行为异常 - 调试宏最好集中管理在一个头里，并在所有需要的地方显式
#include "debug.h"，别指望某个间接包含的头“顺带”提供它
宏调试真正的复杂点不在语法，而在于预处理阶段不可见——你永远看不到宏展开后的中间结果。遇到问题时，先用 g++ -E 或 clang -E 看展开后的代码，比猜半天靠谱得多。
