VSCode调试时停在SIGTRAP是调试器底层机制暴露，并非程序崩溃；常见于符号缺失、地址断点未还原或代码主动触发，需通过调试控制台发signal命令、异常设置禁用或launch.json配置处理。
VSCode调试时为什么突然停在SIGTRAP
这不是你的程序崩溃，而是调试器（gdb或lldb）用SIGTRAP实现断点和单步的底层机制“漏出来了”。常见场景包括：符号缺失导致调试器无法跳过libc初始化代码；用了地址断点（int 3指令）但恢复时没还原原指令；或者代码里写了raise(SIGTRAP)或asm("int $3")，而调试器没过滤。
按F5继续无效？必须显式处理SIGTRAP
F5默认会停住——因为调试器把SIGTRAP当作“第一次机会异常”。要让它继续并转发给进程，得手动干预：
- 打开调试控制台（
Ctrl+Shift+Y），输入signal SIGTRAP（lldb后端）或signal 5（gdb后端） - 在
Debug > Windows > Exception Settings里，取消勾选SIGTRAP或整个Unix signals类别 - 在
launch.json中加配置："miDebuggerArgs": "--eval-command=\"handle SIGTRAP nostop noprint pass\""（gdb）或"setupCommands": [{"description": "Ignore SIGTRAP","text": "process handle -n false -p false -s false SIGTRAP"}]（lldb）
justMyCode: true不是万能的，但必须开
这个选项默认为true，但它只在有完整调试符号时才真正起作用。如果编译没加-g、或二进制被strip过，调试器照样会在_dl_start或__libc_start_main里卡住SIGTRAP。验证方法：在调试控制台执行info symbol $pc，看当前地址能否解析出函数名。
Node.js调试中SIGTERM断点不触发的真相
不是信号没发到，而是debugpy或node --inspect默认拦截了SIGTERM和SIGINT，根本不传给你的process.on('SIGTERM', ...)。实操上：
-
process.on('SIGTERM')必须在server.listen()之后注册，否则监听器还没挂上进程就退出了 - 调试时禁用自动信号拦截：在
launch.json中设"console": "integratedTerminal"且"stopOnEntry": false - 别信
kill -15命令行测试——它可能被调试器吞掉；改用process.kill(process.pid, 'SIGTERM')从内部触发
信号是否被调试器劫持，取决于后端（gdb/lldb/debugpy）而非VSCode本身；不同语言扩展的默认行为差异极大，不能靠经验猜。
