VS Code插件调试必须启动隔离的Extension Host实例并注入自定义settings.json和扩展，因测试进程不读取本地用户设置或已装扩展；需通过vscode-test显式安装依赖、指定临时目录，并确保配置在package.json中声明且作用域正确。
VS Code 插件调试时，不能靠改全局设置或手动切换用户配置来模拟不同环境——那样既不可控，又无法复现 CI 场景。真正可行的方式是启动隔离的 Extension Host 实例，并显式注入自定义 settings.json 和 extensions 状态。
为什么直接改 VS Code 用户设置无效
插件测试运行在独立的 Extension Host 进程中，它不读取你本地 VS Code 的用户设置（~/.vscode/settings.json 或 GUI 中的设置），也不加载你已安装的扩展。你看到的“设置生效了”，只是编辑器主进程的行为，和测试进程完全无关。
常见错误现象：
-
vscode.workspace.getConfiguration()返回空对象或默认值，而非你期望的测试配置 - 插件根据
"myExtension.enabled": true启动逻辑没触发——因为该配置根本没传进去 - 依赖其他扩展（如 ESLint）的功能报
Extension 'esbenp.prettier-vscode' not found，尽管你本地装了
用 vscode-test 注入自定义配置与扩展
vscode-test 提供了 launchFromPath 和 installExtensions 两个关键能力，配合临时工作区目录，可精准控制测试环境。
实操建议：
- 在测试前创建一个干净临时文件夹，写入你的目标
settings.json（例如启用/禁用某功能、设 mock token） - 调用
installExtensions(['ms-python.python', 'esbenp.prettier-vscode'])显式安装依赖扩展（路径需为.vsix或 marketplace ID） - 启动时传入
extraArgs: ['--user-data-dir', tempUserDataDir, '--extensions-dir', tempExtensionsDir] - 确保
testRunner.js中的run()函数在 Extension Host 加载完成后才执行断言，否则vscode.workspace.getConfiguration()可能尚未就绪
workspace.getConfiguration() 读不到你设的值？检查这三点
即使用了 vscode-test，配置仍可能“看不见”，原因很具体：
- 配置项未在插件的
package.json的contributes.configuration.properties中声明——VS Code 不会将其注入到配置 API - 你在
settings.json里写了"myExt.logLevel"，但插件只声明了"myExt.verbose"，字段名必须完全一致 - 配置作用域写错：用户级配置（
application）不会自动覆盖工作区级（resource）配置；测试时建议统一用resource级并指定uri参数
示例验证方式：
const config = vscode.workspace.getConfiguration('myExt', vscode.Uri.file('/fake/path'));
console.log(config.inspect('logLevel'));
看 workspaceValue 和 defaultValue 是否匹配预期。
多用户场景下最易忽略的点：状态存储隔离不彻底
插件若使用 context.globalState 或 context.workspaceState 存数据，测试间容易污染——哪怕你每次新建 tempUserDataDir，如果没在 beforeEach 中显式清除，上一次测试写入的值可能还在。
正确做法：
- 在
beforeEach中调用extension?.activate()前，先清空globalState的 key（可用globalState.keys().forEach(k => globalState.delete(k))） - 避免在
activate()外部初始化单例状态管理器；所有状态读写应绑定到当前ExtensionContext - CI 环境中禁止依赖
process.env传递配置——它不随 Extension Host 隔离，会导致跨测试泄漏
真实项目里，80% 的“本地能过、CI 报错”问题，都卡在这类状态残留上。
