技能介绍

调试 VS Code 扩展为什么这么麻烦

写过 VS Code 扩展的人都遇到过这种场景：逻辑跑在宿主进程里，出问题时 console.log 刷屏、异常堆栈被吞掉，你只能靠断点一点点确认 package.json 里注册的命令、状态栏项或树视图到底在什么时候被调用。扩展的 Webview 又是另一个世界——页面跑在独立的渲染进程中，和扩展宿主之间靠 postMessage 通信，传统的 Node 调试手段在这里完全失效，你往往只能手动 chrome://inspect，再对着一屏幕的源码找线头。

这个技能做了什么

它把扩展调试拆成三条相对独立的链路：

扩展宿主调试：基于调试适配器协议（DAP）启动调试会话，支持设置断点、查看调用栈与检视局部变量，覆盖扩展主进程里的命令注册、事件监听与状态变更逻辑。
Webview 调试：结合 VS Code Extension API 提供的调试钩子，把 Webview 渲染进程接入调试流程，你可以直接在页面脚本里下断点，而不是只盯着消息序列猜。
渲染进程分析：通过 Chrome DevTools Protocol 分析渲染进程，处理 Webview 里的 DOM、网络请求和运行时报错。

具体使用时，一般是先用扩展开发文档里的模板构建出扩展包，再以扩展宿主方式启动调试会话，让 DAP 负责断点与变量检查；需要排查 Webview 问题时，再切换到渲染进程视角继续跟。

适用边界

它的有效范围集中在扩展运行时：构建打包、静态类型检查、单测执行这些环节，仍需依赖 vsce、模板自带的脚本或测试框架，本技能不替代它们。
Webview 调试依赖扩展正确启用调试端口，如果扩展的 enableDebuggers 配置没开，渲染进程这边就接不进来。
上游资料以官方扩展 API 文档为基准，VS Code 大版本升级时 DAP 与 Webview 调试接口的行为可能变化，遇到不兼容要回到 https://code.visualstudio.com/api 对照确认。