VSCode调试“意外中断”90%非代码崩溃，而是调试器暴露本应消化的控制信号：查信号拦截、扩展冲突、源码映射；SIGTRAP停汇编因符号缺失或误设断点；Debug Adapter终止实为Extension Host崩溃；断点空心系source map或debug info失效。
VSCode调试时程序“意外中断”，90%不是代码崩溃，而是调试器把本该自己消化的控制信号暴露给了你——比如停在 SIGTRAP、卡在 int $3 汇编指令、或弹出“Debug Adapter Process Has Terminated Unexpectedly”。先别改代码，重点查三件事：信号是否被错误拦截、扩展是否拖垮宿主、源码映射是否失效。
为什么按F5后突然停在一条汇编指令上（SIGTRAP）
这是调试器用 SIGTRAP 实现断点和单步的底层机制“漏出来”了。它本该被调试器静默处理，但一旦符号缺失、地址断点误设、或程序自己调用了 raise(SIGTRAP)，就会变成用户可见的中断。
- 检查
launch.json是否启用了"justMyCode": false或"stopAtEntry": true—— 这会让调试器在 libc 初始化等系统代码里也响应SIGTRAP - 确认编译时加了
-g且没strip，否则调试器找不到符号，无法跳过非用户代码 - 若已中断，不要直接点继续（F5），在调试控制台输入：
signal SIGTRAP（LLDB）或signal 5（GDB），把信号转给进程本身 - 长期规避：在
launch.json的setupCommands（LLDB）或miDebuggerArgs（GDB）中加入忽略配置，例如："process handle -n false -p false -s false SIGTRAP"
“Debug Adapter Process Has Terminated Unexpectedly”到底是谁的问题
这个报错和你的 launch.json、程序逻辑几乎无关，本质是 VSCode 的 Extension Host 进程在加载调试适配器（如 debugpy、delve）前就挂了。真正线索藏在“Extension Host”输出日志里，而不是调试控制台。
- 第一步必须用
code --disable-extensions启动 VSCode，如果此时调试正常，100% 是某个扩展导致的 - 打开输出面板（
Ctrl+Shift+U），选 “Extension Host”，搜索Extension host terminated unexpectedly，往上翻找堆栈开头那一行，通常直接指向问题扩展 ID（如ms-python.python） - 常见高危组合：
bradlc.vscode-tailwindcss开启classRegex时内存溢出、esbenp.prettier-vscode监听大量.ts文件触发循环格式化 - 临时修复比卸载更有效：在
settings.json中添加"extensions.experimental.affinity": { "ms-python.python": 2 }，让该扩展跑在独立 Node.js 进程里
断点变空心、F10跳到else末尾：源码根本没对上
这不是单步逻辑错了，是调试器压根不知道当前执行的机器码对应哪一行源码。核心矛盾永远在 source map 或 debug info 是否真实可用、路径是否匹配。
- 前端项目：确认构建工具真生成了
.map文件（访问http://localhost:3000/app.js.map能返回合法 JSON），且launch.json中webRoot指向的是开发服务器实际服务的路径（如"${workspaceFolder}/dist"），不是源码目录 - C++ 项目：仅设
CMAKE_BUILD_TYPE=Debug不够，必须在CMakeLists.txt中显式加set(CMAKE_CXX_FLAGS_DEBUG "-g -O0")，并用file ./myapp验证输出含with debug_info - Node.js：不能用
node app.js再 attach，必须启动时带--inspect-brk，否则 V8 来不及加载入口符号，所有断点都会软绑定、步进失准
最常被忽略的一点：SIGTRAP 是否该忽略，取决于它来自哪里——调试器设的断点触发的 SIGTRAP 可安全忽略；但程序里 asm("int $3") 或反调试逻辑主动发的，忽略后可能掩盖真实问题。别全局关掉，先分清信号源头。
