VSCode插件调试需正确配置launch.json与tasks.json：launch.json用"type":"extensionHost"并设runtimeExecutable、--extensionDevelopmentPath、outFiles和webRoot；tasks.json中build任务须设"group":"build"、"isBackground":true且配problemMatcher；extensionKind须按插件类型设为["ui"]、["workspace"]或两者。
VSCode插件开发本身就有调试链路长、启动慢、热更新不可靠的问题，不配好 launch.json 和 tasks.json，你大概率会卡在“改一行代码 → 打包 → 安装 → 重启 VSCode → 手动打开测试窗口 → 点击触发命令”这个循环里，一上午就没了。
launch.json 中的 "type": "extensionHost" 配置要点
这是插件调试的入口，但默认生成的配置往往漏掉关键项，导致断点不命中或无法加载依赖。
-
runtimeExecutable必须显式指向你本地安装的 VSCode 可执行文件（Windows 是Code.exe，macOS 是Visual Studio Code.app/Contents/MacOS/Electron），不能依赖code命令——后者可能调用的是旧版本或 Insiders 版本 -
args数组里要包含--extensionDevelopmentPath=${workspaceFolder}，否则插件不会被识别为开发模式 - 务必加上
"outFiles": ["${workspaceFolder}/out/**/*.js"]，否则 TypeScript 源码断点无法映射到编译后代码 - 如果插件用到了 Webview 或 WebViewPanel，建议加
"webRoot": "${workspaceFolder}"，避免源码映射失败
tasks.json 里如何正确配置 build 任务
插件开发中频繁修改、频繁重载，npm run watch 类型的任务必须和调试器解耦，否则调试器会等构建完成才启动，白白浪费时间。
- 不要把
tsc -w写进launch.json的preLaunchTask；它应该是一个独立的、持续运行的终端任务 - 在
tasks.json中定义一个"group": "build"且"isBackground": true的 task，配合"problemMatcher": ["$tsc-watch"]，这样 VSCode 才能监听 TypeScript 编译错误并实时报错 - 如果使用 webpack 构建（比如带 UI 的 Webview 插件），确保
webpack --watch输出的日志格式能被$tsc-watch或自定义 matcher 识别，否则错误不会出现在 Problems 面板
为什么 extensionKind 配置容易被忽略但很关键
VSCode 1.80+ 引入了 extensionKind 字段（写在 package.json 的 contributes 同级），它决定插件在什么环境下被激活。配错会导致：本地调试时一切正常，但发布后用户装上就完全没反应。
- 纯前端逻辑（如命令、状态栏、Webview）应设为
["ui"]，表示只在 UI 进程加载 - 涉及文件系统操作、调用 Node.js API（如
fs,child_process）的插件，必须设为["workspace"]，否则会因权限限制静默失败 - 混合型插件建议写成
["ui", "workspace"]，但要注意vscode.workspace.fs在 UI 进程不可用，需通过vscode.window.createTerminal()或消息通道间接调用
最常被绕开但代价最大的坑是：改完 package.json 后没重启 Extension Development Host 窗口——VSCode 不会自动 reload extensionKind 或新注册的 contribution point，必须手动关掉再按 F5 启动一次。
