DAP是VS Code调试功能的基石，通过JSON-RPC协议解耦编辑器与语言调试器；它定义Requests、Responses、Events三类消息，需严格遵循初始化时序、路径映射和断点验证等规范。
VS Code 的调试功能背后，靠的是 Debug Adapter Protocol（DAP） —— 一个与语言无关、面向 JSON-RPC 的通信协议。它把编辑器（如 VS Code）和具体语言的调试器（如 Python 的 debugpy、Node.js 的 node-inspect、Go 的 dlv-dap）解耦开来，让 VS Code 不用为每种语言重写一套调试逻辑。
为什么需要 DAP？
在 DAP 出现前，编辑器要支持一种语言的调试，就得直接集成或调用该语言调试器的私有接口（比如 GDB 的 CLI 或 V8 的调试协议），维护成本高、扩展性差、稳定性弱。DAP 提供了一套标准请求/响应模型：
- VS Code 作为 Debug Client，只按 DAP 规范发请求（如
launch、setBreakpoints、continue） - 各语言调试器封装成 Debug Adapter（一个独立进程），负责翻译 DAP 请求为底层调试操作，并将结果/事件（如
stopped、output）按 DAP 格式回传 - 双方通过 stdin/stdout（或 WebSocket）交换 JSON-RPC 消息，协议本身不绑定传输方式
DAP 的核心消息类型
DAP 定义三类消息，全部基于 JSON-RPC 2.0：
-
Requests（请求）：Client 主动发起，带
seq序号和command（如configurationDone、threads），Adapter 必须返回对应Response -
Responses（响应）：Adapter 对 Request 的应答，含
request_seq和success: true/false，失败时带message和可选body -
Events（事件）：Adapter 主动推送（如
initialized、stopped、breakpoint），Client 不需应答，用于驱动 UI 状态更新
所有消息都有固定结构：{"type":"request"/"response"/"event", "seq":N, ...}。VS Code 收到 stopped 事件后，才会显示调用栈、变量、断点状态。
如何开发或调试一个 Debug Adapter
官方推荐用 debug-adapter-node（TypeScript SDK）快速搭建 Adapter。关键步骤包括：
- 实现
DebugSession子类，重写launch/attach/setBreakPointsRequest等方法 - 在对应方法里调用底层调试器 API（例如 spawn
python -m debugpy并与其建立 socket 连接） - 监听底层调试器事件（如断点命中），转换为 DAP
stopped事件并 sendEvent - 用
vscode-debugadapter测试包启动 Adapter，在 VS Code 中配置type为你的 adapter 名称，即可像普通调试器一样使用
VS Code 自带 DEBUG 控制台（Ctrl+Shift+P → “Debug: Toggle Developer Tools”）可查看完整的 DAP 通信日志，对排查 Adapter 卡死、无响应等问题非常关键。
常见误区与注意事项
实际落地中容易忽略几个关键点：
-
Adapter 启动时机：必须在收到
initialize请求并返回initialized事件后，才能处理其他请求；否则 VS Code 会卡在“正在初始化调试器” -
路径映射（pathMapping）：源码路径与目标运行环境路径不一致时（如 Docker 容器内调试），必须在
launch.json中配置sourceMaps+pathMappings，否则断点无法命中 -
多线程/多进程支持：DAP 本身不处理并发，Adapter 需自行管理线程状态同步；VS Code 通过
threads请求获取线程列表，再对每个线程发stackTrace请求 -
断点验证逻辑：Adapter 收到
setBreakpoints后，不能只存断点，必须尝试在底层调试器中设置，并将真实生效位置（verified: true/false）回传，否则 VS Code 无法标记断点是否有效
基本上就这些。DAP 不复杂，但它是 VS Code 调试生态的基石——理解它，你就掌握了扩展任意语言调试能力的钥匙。
