launch.json中type必须为extensionHost，因其是唯一能触发插件激活逻辑、加载activate()函数并支持断点调试的类型；设为node或pwa-node会绕过Extension Host进程，导致vscode对象为空、命令注册失效、断点不可用。
为什么 launch.json 里 type 必须是 extensionHost
VSCode 插件运行在独立的 Node.js 进程中，不是普通网页或脚本。调试时若误设 type 为 node 或 pwa-node，F5 启动后会报错 “No debug adapter found for type 'node'”，因为插件主机（Extension Host）有专属通信协议。extensionHost 是唯一能触发插件激活逻辑、加载 activate() 函数、并支持断点进 extension.ts 的类型。
常见错误现象：
- 按 F5 后弹出空白窗口，控制台无日志
- 断点灰色不可用，提示 “Breakpoint ignored because generated code not found”
- 插件命令注册失败，
vscode.commands.registerCommand不生效
正确配置示例（.vscode/launch.json）：
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Extension",
"type": "extensionHost",
"request": "launch",
"runtimeExecutable": "${execPath}",
"args": ["--extensionDevelopmentPath=${workspaceFolder}"],
"outFiles": ["${workspaceFolder}/out/**/*.js"]
}
]
}
npm install -g yo generator-code 之后，yo code 卡住不动怎么办
yo code 卡住，90% 是网络问题——它默认从 npm registry 拉取模板，而 generator-code 依赖的某些子包（如 inquirer）在国内访问缓慢或超时。不是你本地环境坏了，也不是命令输错了。
实操建议：
- 先执行
npm config set registry https://registry.npmmirror.com切换国内镜像 - 再运行
yo code，如果仍卡在 “? What type of extension do you want to create?”，尝试加--skip-install跳过依赖安装，后续手动npm install - 若卡在 “Installing dependencies...”，关掉终端，删掉生成的
node_modules和package-lock.json，改用pnpm install（比 npm 更稳定）
验证是否成功：生成项目后，运行 npm run compile 应输出 out/extension.js；若报 Cannot find module 'typescript'，说明 devDependencies 没装全，需补 npm install -D typescript @types/vscode。
插件启动后找不到命令，或者 showInformationMessage 不弹窗
这通常不是代码写错了，而是插件没真正激活。VSCode 插件有明确的激活时机，靠 activationEvents 触发，而不是一打开编辑器就执行 activate()。
关键检查点：
-
package.json中的activationEvents是否匹配实际使用场景？比如只写了"*"（启动即激活），但误删了；或写了"onCommand:myext.doSomething"，却没在contributes.commands里声明该命令 -
main字段路径是否指向编译后的 JS 文件？例如"main": "./out/extension.js"，而不是./src/extension.ts - 调试窗口（Extension Development Host）是否已完全加载？有时弹窗被藏在后台，或被系统通知栏折叠
快速验证方法：在 activate() 开头加 console.log('activated')，然后打开调试窗口的开发者工具（Help → Toggle Developer Tools → Console），看是否有输出。没有输出 = 激活事件未触发。
env 文件里的 DIFY_API_KEY 不生效，fetch 报 401
dotenv 在插件进程里默认不自动加载，因为 VSCode 插件运行在受限的 Node.js 环境中，process.env 是只读快照，dotenv.config() 只影响当前模块的 process.env 副本，不会透传给后续 HTTP 请求的 headers。
更可靠的做法是显式读取并注入：
- 不要依赖
process.env.DIFY_API_KEY直接拼 header，改用同步读取：fs.readFileSync('.env', 'utf8')解析（注意打包后需把 .env 放进extensionKind允许的路径） - 生产环境应避免硬编码 API key，改用 VSCode 的
SecretStorageAPI 存储敏感信息：context.secrets.store('dify_api_key', key) - 调试阶段可临时在
launch.json的env字段里注入："env": { "DIFY_API_KEY": "sk-xxx" }，这样process.env才真正可用
容易被忽略的一点：API key 权限是否足够？Dify 控制台里创建的 key 默认可能只开 read 权限，而插件调用 /v1/chat-messages 需要 write 权限，必须手动勾选。
