别在主线程 await 大量 i/o 或 cpu 密集操作；应使用 utility process（非 web worker）、分块调度、cancellationtoken 取消机制及进度反馈。vscode 插件运行于主线程，大文件读取或 json 解析会阻塞事件循环导致 ui 冻结；utility process 支持原生模块和完整 node api，崩溃不影響主进程；所有异步操作须接入 cancellationtoken 防止幽灵任务；需通过 ipc 推送进度并捕获 worker 异常。
直接结论：别在主线程里 await 大量 I/O 或 CPU 密集操作；用 Web Worker、Utility Process 或分块调度 + 进度通知，配合 CancellationToken 防止任务被关闭后继续执行。
为什么 await 一个大文件读取会卡死整个插件 UI
VSCode 插件运行在主渲染进程（Electron 主线程），所有 await 都是 Promise 微任务，但底层调用如 fs.readFile、fetch 或解析万行 JSON，若未做流式/分块处理，会一次性把数据载入内存并阻塞事件循环。用户点击按钮后界面“冻结”，右键菜单弹不出、输入框失焦、甚至终端粘贴失效——这不是卡在 JS 层，而是 V8 线程被占满。
- 典型错误：直接
await vscode.workspace.fs.readFile(uri)读取 >50MB 的日志文件 - 更隐蔽的坑：用
JSON.parse()解析未限制长度的响应体，V8 解析器单次调用可能耗时数百毫秒 - Node.js 后端插件（如 Language Server）若在
onRequest中同步处理大 payload，也会拖慢整个 LSP 响应链
Web Worker 不是万能解，Utility Process 才是 VSCode 官方推荐方案
VSCode 自 1.80 起正式支持 UtilityProcess（基于 Electron 的 utilityProcess.fork），它比 Web Worker 更适合插件场景：能 require 原生模块、访问完整 Node.js API、支持 IPC 双向通信，且崩溃不会影响主进程。
- 不要用
new Worker(...)加载.ts文件——Worker 不识别 TS，需先编译为 JS 并确保无vscode模块引用 - 正确做法：在插件激活时启动 Utility Process，传入任务参数，用
process.send()和process.on('message')通信 - 示例路径：
./worker/parse-large-json.js，启动时指定type: 'module'和env: { NODE_OPTIONS: '--max-old-space-size=4096' }防 OOM - 注意：Utility Process 无法调用
vscode.window.showInformationMessage等 UI API，进度必须通过 IPC 推送回主进程再显示
主线程中必须加 CancellationToken，否则关掉编辑器插件还在后台跑
用户关闭文件夹、禁用插件、甚至直接退出 VSCode 时，主线程会触发 context.subscriptions.push(...) 清理逻辑，但正在 await 的 Promise 若没被取消，就会变成“幽灵任务”——既不报错也不结束，还持续占用资源。
- 所有异步操作入口必须接收
token: vscode.CancellationToken参数 - 在关键 await 前插入
token.onCancellationRequested(() => { throw new Error('canceled'); }) - 对 fs 操作，改用
vscode.workspace.fs.readTextFile(uri, { token })（内置支持 cancel） - 自定义 fetch 请求需手动封装 AbortController：
const controller = new AbortController(); token.onCancellationRequested(() => controller.abort()); fetch(url, { signal: controller.signal })
进度反馈不是锦上添花，而是防止用户误操作的关键
没有进度提示的长时间任务，用户第一反应是点重试、关终端、甚至强制杀进程——这会导致数据损坏或状态不一致。VSCode 提供了原生的 vscode.Progress API，但它只在任务开始时注册，无法动态更新子阶段。
- 用
vscode.window.withProgress包裹顶层调用，location: vscode.ProgressLocation.Notification最稳妥（不会遮挡编辑器） - 若需分阶段提示（如“解析中… → 校验中… → 写入中…”），必须自己维护状态机，每次变更都调用
progress.report({ message: 'xxx', increment: 25 }) - 避免在 progress 回调里做耗时操作——它运行在主线程，report 调用太频繁（如每毫秒一次）反而加重卡顿
- 真实案例：某代码生成插件在 3s 无响应后自动弹出 “是否继续？” 确认框，而不是静默等待，大幅降低误操作率
最易被忽略的一点：Utility Process 的 stdout/stderr 默认不捕获，错误堆栈全丢在控制台里看不到。上线前务必在 worker 进程中加 process.on('uncaughtException', console.error) 并通过 IPC 上报，否则生产环境出问题连日志都捞不到。
