VSCode插件调试失败主因是配置与环境不匹配：launch.json的request类型（launch/attach）须正确选择，package.json的main和activationEvents需准确对应，tsconfig.json的outDir与launch.json的outFiles必须一致且启用sourceMap，修改代码后须重启Extension Host并确保已构建。
VSCode插件调试不是“装好插件就能断点”，绝大多数失败源于调试配置与运行时环境不匹配——比如用 launch.json 启动 Extension Development Host，却没确认插件入口文件路径是否正确，或没在 package.json 的 main 字段里指向实际的 JS/TS 入口。
launch.json 里 "request": "launch" 和 "request": "attach" 完全不是一回事
新手常把两者混用，导致调试器连不上、进程一闪而过或直接报错 Cannot connect to runtime process。
-
"request": "launch"是让 VS Code 自己拉起一个干净的 Extension Development Host 实例，并加载你的插件。这是开发阶段默认且最安全的方式 -
"request": "attach"是去连接一个**已运行**的 VS Code 实例（比如你手动打开了另一个窗口并安装了你的插件），需要额外配port、address，且目标实例必须以--inspect-extensions=9229启动，否则 attach 失败 - 误用
attach而没做前置启动和端口暴露，调试器会一直等待连接，最终超时退出
package.json 的 "main" 和 "activationEvents" 必须对得上
调试器能进断点，前提是 VS Code 真的加载并执行了你的代码。如果 main 指向了不存在的文件，或 activationEvents 写成 onCommand:xxx 却没注册对应命令，插件根本不会激活，断点自然无效。
- 检查
main字段路径是否相对于package.json，比如"main": "./out/extension.js"，确保构建后该路径真实存在 -
activationEvents不要写死冷门事件；开发期建议先用*或onStartup，避免因触发条件未满足导致插件静默 - 改完
package.json后，必须重启 Extension Development Host（按Ctrl+Shift+P→Developer: Restart Extension Host），否则变更不生效
tsconfig.json 编译输出路径和 launch.json 的 outFiles 必须严格一致
TypeScript 插件调试失败，80% 出在这儿：源码是 .ts，但调试器只认 .js 和 .map。如果 outFiles 指向错误，VS Code 找不到 sourcemap，就只能停在编译后代码里，或者干脆不命中断点。
-
tsconfig.json中outDir设为./out，则launch.json的outFiles必须包含"${workspaceFolder}/out/**/*.js" - 别漏掉
sourceMap: true和inlineSources: true（后者让 source 嵌入 map，调试更稳） - 如果用了
esbuild或vite构建，outFiles要按实际产物路径写，不能照抄 TS 默认配置
调试时修改代码，热重载不会自动生效
VS Code 的 Extension Development Host 不支持像 Web 那样保存即刷新。改了代码不手动重启 host，调试器永远跑的是旧版本。
- 每次改完逻辑，务必按
Ctrl+Shift+P→Developer: Restart Extension Host，否则断点位置和行为都可能错乱 - 可以配一个快捷键绑定此命令，避免反复打开命令面板
- 注意：重启 host 会关闭所有已打开的 Dev Host 窗口，已设断点不会丢失，但需重新触发插件激活逻辑（比如再执行一次命令）
最易被忽略的是：插件调试依赖完整的构建流程。没跑 npm run compile（或等效命令）就直接点 ▶️，outFiles 路径下压根没文件，调试器连入口都找不到——这种情况下，VS Code 往往静默失败，连错误提示都不给。
