Windows下用IsDebuggerPresent最直接，它读取PEB的BeingDebugged标志位；Linux需解析/proc/self/status的TracerPid字段；macOS需调用task_info检查TASK_IS_TRACED标志。
Windows下用IsDebuggerPresent判断最直接
在Windows平台，IsDebuggerPresent是标准且轻量的API，它读取PEB（进程环境块）中的BeingDebugged标志位，几乎无开销。调用前不需要额外链接或初始化。
- 必须包含
<windows.h>头文件 - 返回
TRUE表示当前进程正被调试器附加（包括Visual Studio、x64dbg、WinDbg等） - 即使调试器处于暂停状态，只要已附加，该函数仍返回
TRUE - 注意：它无法区分是“正在单步执行”还是“仅附加未中断”，只反映调试器是否存在
Linux下检查/proc/self/status里的TracerPid
Linux没有系统级API直接暴露调试状态，但内核会在/proc/self/status中写入TracerPid字段——当值为0时表示无调试器，非0（通常是调试器进程PID）则表示被ptrace跟踪。
- 需用
std::ifstream读取该文件，然后按行解析，匹配TracerPid:开头的行 - 不要依赖
/proc/self/stat或getppid()，它们不可靠（比如GDB可能fork子进程，父PID不变） - 注意权限：容器环境中
/proc可能被挂载为只读或受限，读取失败时应视为“无法确定”，而非默认“未调试” - 示例片段：
std::string line; while (std::getline(file, line)) { if (line.substr(0, 10) == "TracerPid:") { return std::stoi(line.substr(11)) != 0; } }
跨平台封装时别忽略macOS的task_is_traced
macOS需用task_info配合TASK_BASIC_INFO获取task_basic_info_data_t结构体，再查flags & TASK_IS_TRACED。这比Windows/Linux更重，且需要mach头文件和链接-framework CoreServices（实际只需-lmach）。
- 必须先用
mach_task_self()获取当前任务端口 -
task_info调用可能失败（如沙盒限制），需检查返回值是否为KERN_SUCCESS - 即使调试器未活跃暂停，只要通过
lldb或Xcode附加过，TASK_IS_TRACED就会置位 - 不建议用
sysctl查kern.proc.pid，因为macOS对调试状态隐藏得更严，该路径不暴露tracer信息
反调试误判常见坑：IDE插件、杀毒软件、代码混淆工具
很多开发环境或安全软件会主动设置调试标志位来实现功能，导致IsDebuggerPresent或TracerPid返回真，但你并没有手动启动调试器。
立即学习“C++免费学习笔记（深入）”；
- VS的“启用本机代码调试”选项开启时，即使没按F5也会注入调试器逻辑
- 某些杀软（如360、火绒）用
ptrace监控进程，Linux下TracerPid会显示其PID - 使用
UPX或Themida加壳后，解包阶段常触发调试检测逻辑，造成误报 - 真正需要“防调试”的场景，不能只依赖单一检测——要组合时间差、断点指令、SEH异常等，但普通程序只需知道“是否被用户有意调试”就够了
跨平台检测最难的不是实现，而是定义清楚“什么叫在调试器下运行”：是进程被附加？有调试寄存器设置？还是用户正在交互式调试？不同场景答案不同，别让一个函数名误导你做过度判断。
