直接用GDB查悬挂指针几乎无效，因为GDB只响应SIGSEGV等信号，而悬挂指针读操作常不触发信号，且不跟踪malloc/free及指针生命周期；必须启用AddressSanitizer插桩才能精准定位分配与释放位置。
VSCode 本身不捕获悬挂指针，真正起作用的是编译器插桩工具（如 AddressSanitizer），GDB/LLDB 只负责在崩溃现场停住并展示上下文。
为什么直接用 GDB 查悬挂指针几乎无效
悬挂指针访问时，内存可能已被复用、未被清零、甚至仍存旧值——程序未必立即崩溃，GDB 无法主动标记“这块内存已失效”。它只响应 SIGSEGV 等信号，而很多悬挂访问（尤其读操作）不会触发信号，导致静默错误。
-
gdb不拦截 malloc/free，也不跟踪指针生命周期 - 即使停在
segfault处，调用栈里往往只显示operator[]或*ptr，看不出原始释放点 - LLDB 同样不提供“这个指针已被 delete”的元信息
必须启用 AddressSanitizer 编译插桩
ASan 在每次内存访问前插入检查，一旦读写已释放/越界内存，立刻终止并打印完整堆栈（含分配和释放位置）。
- Linux/macOS：编译时加
-fsanitize=address -g -O1（-O1避免内联干扰定位） - Windows（Clang/LLVM）：用
clang++ -fsanitize=address -g，MSVC 不支持 ASan - 务必去掉
-DNDEBUG，否则 ASan 的运行时检查会被剔除 - 链接时若报错
undefined reference to __asan_init，说明没加-fsanitize=address或混用了不同编译器
launch.json 必须设 "externalConsole": true
ASan 的报错输出很长，含多行堆栈和内存映射，VSCode 内置终端会截断或乱码，导致关键信息（如 freed by thread T0 here:）丢失。
立即学习“C++免费学习笔记（深入）”；
- 配置项必须是布尔值
true，不是字符串"true" - 启动后弹出的外部终端窗口才能完整显示 ASan 的彩色高亮报告
- 若调试器路径不对（如
"miDebuggerPath": "lldb"但实际是gdb），ASan 崩溃后无法进入调试状态
崩溃后用 LLDB/GDB 查现场的关键动作
ASan 崩溃时已记录所有线索，此时进调试器不是为了“找 bug”，而是验证上下文、复现路径、确认是否真为悬挂。
- 输入
bt看完整调用栈，重点关注freed by和allocated by两段地址 - 用
frame select N切到释放帧，再info registers看rdi/rax是否存着那个悬挂地址 - 别依赖
print *ptr——ASan 崩溃后该内存页通常已被 mmap 保护，强行读会二次崩溃 - 若想单步复现，可在释放前加断点，然后用
watch -l *(int*)0x7f8...监视具体地址（需知道确切地址）
悬挂指针的本质是时序错误，ASan 报告里的“allocated at”和“freed at”行才是根因所在；盯着崩溃那一行代码看，90% 会错过真正问题。
