VSCode调试崩溃需配置launch.json：设"justMyCode": false显式显示全部调用帧，"console": "integratedTerminal"确保完整traceback输出，Python加"subProcess": true捕获子进程异常，Node.js需runtimeArgs加--trace-uncaught，C++须正确配置miDebuggerPath和setupCommands以显示符号与内存。
VSCode调试器崩溃时自动打印调用栈：关键靠 launch.json 的 justMyCode 和 console 配置
VSCode 本身不会“自动打印崩溃时的完整调用栈和内存数据”，它依赖底层调试器（如 Python 的 ptvsd / debugpy，Node.js 的 node --inspect，C++ 的 cppdbg）是否在异常未捕获时暂停并暴露上下文。真正起作用的是：让调试器在抛出未处理异常时中断，并把堆栈、局部变量、线程状态等通过 UI 或控制台显式呈现出来。
以 Python 为例，debugpy 默认会在未处理异常处暂停，但如果你看到的只是 Exception has occurred: ... 一行，没展开堆栈或变量，大概率是 justMyCode 过滤太狠，或者控制台输出被抑制了：
-
justMyCode: true（默认）会隐藏标准库/第三方包帧，导致你点开调用栈只看到顶层函数，看不到真实异常源头 —— 调试崩溃问题时建议设为false -
console: "integratedTerminal"比"internalConsole"更可靠，能确保异常 traceback 完整输出到终端，且支持复制 - 如果用了
try/except吞掉了异常但没 re-raise，调试器根本收不到信号 —— 确保异常最终未被捕获
Python 崩溃调试必须加的 launch.json 字段
仅靠默认配置，VSCode 在 ZeroDivisionError 或 KeyError 发生时可能一闪而过，或只停在 __main__.py 最后一行。要稳定捕获并展示完整现场，这几个字段不能少：
-
"justMyCode": false：强制显示所有帧，包括内置函数、importlib、runpy等 —— 不然你永远找不到__import__里哪行触发了 import error -
"console": "integratedTerminal"：避免 internalConsole 对多行 traceback 渲染不全的问题，尤其带 Unicode 或长路径时 -
"subProcess": true（可选但推荐）：如果你的程序 fork 子进程（比如用multiprocessing），不加这个，子进程崩溃完全不会被主调试器感知 - 别漏掉
"stopOnEntry": false，否则一启动就停，干扰异常复现流程
示例片段：
{
"configurations": [
{
"name": "Python: Crash Debug",
"type": "python",
"request": "launch",
"module": "myapp.main",
"justMyCode": false,
"console": "integratedTerminal",
"subProcess": true,
"stopOnEntry": false
}
]
}
Node.js 崩溃时看不到完整堆栈？检查 --trace-uncaught 和 runtimeExecutable
Node.js 默认只打印错误类型和消息（如 TypeError: Cannot read property 'x' of undefined），没有文件行号和调用链。这不是 VSCode 的锅，而是 Node 运行时没开追踪。
- 必须在
launch.json的runtimeArgs中加--trace-uncaught，否则调试器收不到原始堆栈帧 - 如果用的是 nvm 或自定义 Node 版本，
runtimeExecutable必须指向真实可执行路径（如~/.nvm/versions/node/v18.17.0/bin/node），否则--trace-uncaught可能被忽略 -
console: "integratedTerminal"同样重要 ——internalConsole会截断长堆栈，尤其涉及 Promise 链时 - 注意：ESM 模块下
unhandledRejection事件需单独监听，VSCode 不自动捕获，得自己加process.on('unhandledRejection', ...)
C++ 程序崩溃后看不到内存快照？核心是 miDebuggerPath 和 setupCommands
Windows 上用 cppvsdbg（MSVC）、Linux/macOS 上用 cppdbg（GDB/LLDB），它们默认只停在崩溃点，不自动 dump 内存或打印寄存器。想看到崩溃瞬间的栈帧、局部变量、甚至内存地址内容，得手动喂命令：
- 确认
miDebuggerPath指向的是完整 GDB/LLDB（不是简化版），比如 Ubuntu 上别用gdb-minimal - 在
setupCommands里加["-enable-pretty-printing"]（LLDB/GDB）让 STL 容器可读，否则std::vector显示成一串地址 - 加
["-exec info registers"]和["-exec x/10xg $rsp"]（GDB）可手动查寄存器和栈顶内存 —— 但这是临时方案；真要自动化，得写postLaunchCommands调用dump memory - Windows 下若用 MinGW，务必关掉
externalConsole: true，否则崩溃弹窗会抢走调试器控制权
崩溃时最常被忽略的一点：符号文件（.pdb 或 .debug）没生成或路径不对。没有符号，VSCode 就算停住了，也只显示 ??? 地址，没法映射回源码行。
