开发vscode调试适配器的核心是确保initialize、launch、setbreakpoints三请求被正确接收并返回合规响应；协议握手失败则调试会话无法启动，常见原因包括type不一致、激活事件缺失、适配器进程启动失败、launch.json字段缺失等。
直接上结论：开发一个能用的 VSCode 调试适配器，核心不是写多复杂的逻辑，而是确保 initialize、launch、setBreakpoints 三个请求能被正确接收并返回合规响应；其他功能（如变量查看、调用栈）可以后续补，但协议握手失败，整个调试会话根本启动不起来。
为什么 launch.json 配置后点 F5 没反应？
绝大多数“没反应”问题，其实卡在协议初始化阶段，VSCode 根本没和你的适配器建立通信。常见原因包括：
-
package.json中contributes.debuggers.type和launch.json里的type不一致，比如扩展声明的是"type": "mylang"，但用户配置写成了"type": "my-language" - 没设置正确的激活事件：
"activationEvents": ["onDebugResolve:mylang"]缺失或拼错，导致插件压根没被加载 - 适配器进程启动失败但无报错：比如
DebugAdapterExecutable指向的脚本路径错误、Node.js 版本不兼容、或脚本里抛了未捕获异常（此时需查Output → Log (Extension Host)） -
launch.json缺少必需字段：例如program字段未定义，而你在configurationAttributes中把它标为"required": true，VSCode 会静默跳过该配置项
如何验证 DAP 通信是否真正跑通？
别等断点命中才确认——先看最底层的消息收发。最简单有效的办法是加日志到适配器的 stdin/stdout 处理层：
VSCode 1.118
下载
微软正式发布 Visual Studio Code 1.118 版本 。本次更新重点强化了 AI 开发体验与企业管理能力，其中最引人注目的是新增 Copilot CLI 远程控制功能，允许开发者通过手机或网页远程监控和接管 AI 会话 。同时，为了提高 AI 的运行性价比，新版本优化了令牌缓存策略以降低成本 。此外，1.118 版还引入了 Chronicle 本地历史追踪、TypeScript 7.0 支持以及更严格的企业级访问管控 。
- 在
readline的line事件里打印原始输入，确认 VSCode 是否发来了Content-Length头和后续 JSON - 在
sendEvent或sendResponse前打日志，确认你的适配器确实执行到了响应逻辑 - 关键节点加
console.error（不是console.log），因为只有console.error默认会出现在Developer Tools → Console面板中 - 如果用
vscode-debugadapter库，启用其内置日志：LoggingDebugSession构造时传入{ logFile: './dap.log' }
断点设置了但程序不暂停？检查这三处
断点不命中，90% 不是解释器问题，而是适配器没把“暂停信号”正确上报给 VSCode：
- 你的脚本语言解释器真的触发了暂停吗？加个
console.log('PAUSED at line X')到解释器内部，确认它真停了 - 暂停后是否调用了
this.sendEvent(new StoppedEvent('breakpoint', threadId))？漏掉这句，VSCode 就永远不知道该停下来 -
StoppedEvent的threadId必须是你之前通过ThreadsRequest返回过的 ID，否则 VSCode 会忽略该事件 - 断点位置是否匹配源码映射？如果你的脚本是编译/转译后的，需在
SourceBreakpoint中提供sourceReference或确保source.path与launch.json中的program路径一致
最容易被忽略的点是：DAP 协议要求所有响应必须带 request_seq 字段，且值要和请求中的 seq 完全一致；少一个字段、错一个数字，VSCode 就会断开连接，但不会明确报错——它只会安静地关闭调试会话窗口。
