vscode插件中不能直接new worker('./xxx.js')，因electron限制不支持相对路径或动态字符串路径，会报script无法访问错误；必须用vscode.env.asexternaluri()转绝对url或esm环境下结合import.meta.url动态解析。
VSCode插件中直接在主线程跑CPU密集型计算，页面必然卡顿——这不是代码写得不够好，而是浏览器和Electron渲染进程的底层限制决定的。唯一可靠解法是把计算逻辑移出主线程，用Web Worker承载。
为什么VSCode插件里Worker不能直接new Worker('./xxx.js')
VSCode（尤其是Electron版）对Worker加载路径有严格约束：它不支持相对路径或动态字符串构造的脚本路径，new Worker('./compute.js') 会直接报 Failed to construct 'Worker': Script at ... cannot be accessed。必须通过 vscode-webview-resource 协议或预注册的URL方案加载。
常见错误现象：
- 本地开发时Worker文件404，控制台显示
NetworkError when attempting to fetch resource - 打包后Worker路径失效，
self.location.href在Worker内返回about:blank，导致动态import()失败
正确做法：
- 把Worker脚本放在插件
dist/目录下，与主逻辑同级（如dist/compute.worker.js） - 使用
vscode.Uri.file()转为绝对路径，再调用vscode.env.asExternalUri()得到可访问URL - 或改用
Worker构造函数的options.type = 'module'+import.meta.url动态解析（仅限ESM环境）
如何在Worker里安全使用Node.js内置模块或VSCode API
不能。Worker线程没有 require、没有 process、无法调用 vscode.window.showInformationMessage 等任何UI或Node API。所有依赖必须满足两个条件：纯JS、无副作用、不访问全局对象。
典型踩坑点：
- 误在Worker里
import { readFileSync } from 'fs'→ 报错ReferenceError: require is not defined - 试图调用
vscode.workspace.findFiles→ 报错Cannot access 'vscode' in worker context - 传入含
Buffer或Uint8Array的对象但未用transfer→ 主线程收不到数据或内存泄漏
可行替代方案：
- 所有I/O操作（读文件、查工作区）必须在主线程完成，只把纯计算部分（如JSON解析后做聚合、排序、滤波）发给Worker
- 需要第三方计算库（如
mathjs、ml-matrix）时，确认其是否为纯ESM、无Node依赖；否则需手动剥离或换用轻量实现 - 大数组传输务必用
transfer：例如worker.postMessage({data}, [data.buffer])，否则克隆开销极大
VSCode插件中Worker通信怎么避免消息堆积和内存泄漏
主线程频繁 postMessage（比如编辑器每输入一个字符就触发一次计算），而Worker处理慢，会导致消息队列持续积压，最终OOM。这不是Worker本身问题，而是通信节奏失控。
关键控制点：
- Worker内部不要无条件
self.onmessage—— 改用self.addEventListener('message', handler, {once: true})配合self.postMessage后自动注销，防止重复绑定 - 主线程侧加防抖：用
DebouncedRunner（VSCode内置）或自定义节流逻辑，确保100ms内只提交最后一次任务 - 每次
postMessage前检查Worker状态：if (worker && worker.readyState === WorkerState.Running)，避免向已终止Worker发消息 - Worker执行完必须显式调用
self.close()（尤其长周期任务），否则线程常驻占用内存
示例节流逻辑（主线程）：
const debouncer = new vscode.utils.DebouncedRunner(150);
debouncer.task = () => {
worker.postMessage({ type: 'process', payload: data });
};
// 触发时调用 debouncer.trigger()
Electron环境下Worker和Utility Process该怎么选
VSCode桌面版实际提供两套并行机制：Web Worker（受限JS环境）和 UtilityProcess（完整Node.js子进程）。选哪个取决于任务性质。
判断依据：
- 如果任务只需纯计算、不依赖Node API、数据量Web Worker，启动快、资源开销小、与WebView兼容性好
- 如果任务要调用
child_process、sqlite3、ffmpeg.wasm或需长期持有大内存（>500MB）→ 必须用UtilityProcess，它拥有完整Node上下文和独立V8实例 - 注意：Utility Process无法直接访问VSCode API，仍需通过IPC与主进程通信，且调试难度显著高于Worker
容易被忽略的细节是：Worker的 self 全局对象不等于 window，也没有 document 或 fetch（除非Electron启用了 nodeIntegrationInWorker，但VSCode默认禁用）。所有网络请求必须由主线程代劳，Worker只做“算完就走”的离线计算。
