vscode 1.92+ 中 vscode.workspace.workspacefolders 返回 null 是因初始化时机收紧所致，并非加载失败；需改用 vscode.workspace.ondidchangeworkspacefolders 监听，或在 ondidopentextdocument 等事件中首次检查，不可在 activate() 内直接读取。
VSCode 1.92+ 更新后 vscode.workspace.workspaceFolders 返回 null 的常见原因
新版 VSCode（特别是 1.92 起）对多根工作区初始化时机做了收紧，导致部分插件在激活早期调用 vscode.workspace.workspaceFolders 时返回 null，而非空数组。这不是 bug，而是生命周期变更的明确行为。
典型触发场景：插件在 activate() 回调里立刻读取工作区路径，或依赖 onStartupFinished 但未正确监听。
- 必须改用
vscode.workspace.onDidChangeWorkspaceFolders监听初始化完成事件，而不是轮询或延时 - 若需立即获取路径，应包裹在
vscode.workspace.onDidOpenTextDocument或vscode.window.onDidChangeActiveTextEditor后首次触发时检查，更稳妥 - 注意：即使工作区已打开，
vscode.workspace.workspaceFolders在扩展刚激活时仍可能为null，这是设计使然，不是加载失败
第三方语言服务器（LSP）插件在 VSCode 1.93 中报 Connection to server got closed 的修复点
1.93 默认启用了更严格的 IPC 连接验证，尤其影响未显式设置 transport 或复用旧版 vscode-languageclient（
错误日志中若出现 TypeError: Cannot read property 'send' of undefined 或连接中断前有 Invalid message header，基本可定位为此类兼容问题。
- 升级
vscode-languageclient至^9.0.0或更高，它默认启用StreamMessageReader/Writer并修复 header 解析逻辑 - 若自行管理进程通信，确保子进程 stdout/stdin 使用
utf8编码，且不带 BOM；Windows 下避免用spawn的shell: true启动 LSP 服务 - 禁用
"editor.suggest.showWords": false等实验性配置项——它们曾意外干扰 LSP 初始化队列
vscode.extensions.getExtension() 在插件依赖链中返回 undefined 的调试方法
当 A 插件声明依赖 B 插件（通过 extensionDependencies），但运行时 vscode.extensions.getExtension('B.id') 返回 undefined，大概率不是安装问题，而是加载顺序或激活策略冲突。
VSCode 不保证依赖插件一定“先激活”，只保证“已安装”。是否激活取决于用户操作、激活事件触发条件及插件自身 activationEvents 配置。
- 检查 B 插件的
package.json中activationEvents是否过于狭窄（例如仅onCommand:xxx），导致未被触发激活 - A 插件不应在
activate()内直接调用getExtension().activate()，而应监听vscode.extensions.onDidChange，待getExtensions().find(...).isActive === true后再使用 - 临时验证方式：在开发者工具控制台手动执行
vscode.extensions.all.find(e => e.id === 'B.id')?.isActive，确认状态
Webview 插件在 VSCode 1.90+ 中加载本地资源失败（net::ERR_FILE_NOT_FOUND）的关键限制
新版强制 Webview 使用 vscode-resource: 协议加载本地文件（如图片、CSS），且不再支持 file:// 或相对路径直接引用。此前能跑的代码，更新后常在控制台看到大量 404。
该限制同时作用于 webview.html 中的 <img src>、<link href> 和 JS 动态创建的资源请求。
- 所有本地资源路径必须经
vscode.Uri.file('/path/to/asset').with({ scheme: 'vscode-resource' })转换，再转成字符串传入 HTML - 不要拼接字符串构造
vscode-resource://URI——scheme 参数必须由Uri.with()注入，否则会被安全策略拦截 - CSS 中的
url()不支持自动转换，需提前用 JS 注入 style 标签，或改用 base64 内联小资源
真正麻烦的不是 API 变了，而是这些变更往往不抛错、不警告，只让功能静默失效。最易被忽略的是：你以为插件“启动成功”了，其实关键资源根本没加载，而控制台又没报错——得手动检查 Network 面板里 vscode-resource 请求的状态码。
