VSCode调试插件本质是Debug Adapter Protocol（DAP）的客户端封装，不内置语言调试逻辑，而是通过独立调试适配器（如debugpy、vscode-js-debug）与目标运行时通信；launch.json中type字段决定调用哪个适配器，必须匹配已安装插件及运行时环境，否则报“Configured debug type 'xxx' is not supported”。
VSCode调试插件本质是语言服务的客户端封装
VSCode本身不内置具体语言的调试逻辑，所有调试能力都依赖于debug adapter（调试适配器）——它是一个独立进程，负责与目标运行时（如Node.js、Python解释器、Chrome DevTools Protocol）通信。插件只是把Debug Adapter Protocol (DAP)的配置、UI绑定和启动流程包装成用户可点选的界面。
这意味着：你装的Python Debugger插件，实际在后台启动的是debugpy；JavaScript Debugger（已内置）调用的是vscode-js-debug；而C/C++插件背后是cppvsdbg或gdb/lldb适配层。不是插件“会调试”，而是它帮你把launch.json里写的type、request、program等字段，翻译成DAP能理解的JSON-RPC消息。
- 常见错误现象：
Cannot connect to runtime process，往往是因为适配器没启动成功，或端口被占，而非插件本身坏了 - 使用场景：调试前端时选
chrome类型，后端Node服务用node类型，本地Python脚本用python类型——类型名必须和已安装的适配器匹配 - 参数差异：
port、address、stopOnEntry这些字段，每个适配器支持程度不同，不能照搬其他语言的launch.json
launch.json里的type字段决定调试器归属
type不是随便写的字符串，它是VSCode路由调试请求的关键键值。VSCode启动调试前，会扫描所有已启用插件，查找声明了对应type的package.json贡献点。比如"type": "python"会触发ms-python.python插件注册的适配器；"type": "pwa-chrome"则由ms-vscode.js-debug响应。
如果你手动改了type但没装对应插件，F5后只会看到Configured debug type 'xxx' is not supported——这不是配置错，是生态没对齐。
- 容易踩的坑：复制别人项目里的
launch.json，直接粘贴进一个纯HTML项目，"type": "node"会报错，因为没装Node调试支持（虽然VSCode自带，但需确认node在PATH里） - 验证方法：打开命令面板（
Ctrl+Shift+P），输入Debug: Select and Start Debugging，看下拉列表里有哪些type可选，那些就是当前环境真正可用的调试器 - 性能影响：每个调试适配器都是单独进程，同时开多个调试会话（比如前后端一起调）会明显增加内存占用，
top或任务管理器里能看到多个node或python进程
调试插件无法绕过目标环境的运行时限制
再强的插件也不能让Python代码在浏览器里断点，也不能让TypeScript源码在未启用sourceMap的生产构建中跳转到原始行。调试能力上限，永远受制于目标平台是否暴露调试接口、是否生成可映射的符号信息。
例如：Live Server插件起的是静态HTTP服务，不带调试协议；你没法在它上面设断点。想调试前端JS，得用chrome或pwa-msedge类型，并确保页面加载时启用了devtools，且资源未被压缩混淆。
- 典型卡点：
Breakpoint ignored because generated code not found，说明webpack/vite没输出sourceMap，或者launch.json里webRoot路径配错了 - 兼容性注意：旧版
Debugger for Chrome插件已废弃，必须用js-debug（内置），否则连不上新版Chrome的CSP策略 - 真实约束：嵌入式开发中，J-Link或OpenOCD调试需要硬件支持，VSCode插件只是串口转发层，烧录失败或断点不命中，问题一定出在
openocd.cfg或硬件连接上，不是插件bug
自定义调试适配器需要实现DAP标准接口
如果你真要为自家DSL或私有运行时写调试支持，核心不是写VSCode插件，而是实现一个符合Debug Adapter Protocol规范的独立程序（可以是Go/Python/Node写的二进制或脚本），然后在VSCode插件里通过DebugAdapterDescriptorFactory告诉编辑器：“这个type，请去调用我指定的可执行文件”。
微软官方提供了debug-adapter-node等模板库，但关键在于：你得自己解析断点位置、注入调试指令、捕获运行时状态——VSCode只负责画UI、传消息、收响应。
- 复杂点：DAP没有规定如何“单步执行”，不同运行时语义差异极大（比如协程暂停 vs 线程挂起），适配器必须做语义对齐
- 容易被忽略的地方：调试器退出时，必须显式发送
terminated事件，否则VSCode调试面板会卡在“正在停止”状态，反复重启也清不掉 - 最小验证：写个打印
stdinJSON并回写initialized响应的脚本，就能让VSCode识别为合法适配器——协议本身很薄，难点全在运行时集成
