webview 与主进程通信吞吐量低的根源在于消息设计不当：应避免高频小数据包、禁用自动序列化大对象、用 web worker 处理重负载、确保资源加载合规。
Webview 与主进程通信吞吐量低，根本不是 postMessage 本身慢，而是消息格式、频率和序列化方式不当导致的无效负载堆积和主线程阻塞。
避免高频小数据包：用防抖 + 增量 diff 替代实时同步
直接在 onDidChangeTextDocument 里每敲一个字就 postMessage 一次，会触发大量重复 DOM 更新和 JSON 序列化开销，尤其当 WebView 内含 React/Vue 时，reconcile 成本飙升。
- 扩展端使用防抖（如
DebouncedRunner(150)）聚合变更，只在用户停顿后发送最终状态 - WebView 端不全量替换数据，改用
reaction或useEffect监听变更字段，仅更新受影响的组件区域 - 对列表类数据（如符号表、变量快照），传
{ type: 'update', id: 'var-42', patch: { value: 'newVal' } }而非整个数组
禁用自动序列化大对象：手动控制传输边界
VSCode 的 postMessage 默认调用 JSON.stringify，若传入含 Buffer、Map、循环引用或未定义字段的对象，不仅序列化慢，还会静默丢弃字段甚至卡死。
- 扩展端发送前做白名单裁剪：
JSON.stringify(obj, ['name', 'type', 'range']) - 禁止传
vscode.Uri、TextDocument等原生对象——它们无法被序列化，应提前转为 plain object - 大体积数据（如 AST JSON、源码快照）改用
webview.postMessage({ type: 'loadChunk', data: base64 })分块传输，WebView 端用atob()+JSON.parse懒解析
绕过主线程瓶颈：用 Web Worker 处理消息编解码
当单次消息 payload > 1MB 或需频繁转换（如 source map 解析、token 高亮计算），JS 主线程会因 JSON 解析/生成阻塞 UI 响应，WebView 表现为“点击无反馈”或滚动卡顿。
- 在 WebView 中启动专用 Worker：
new Worker(webview.asWebviewUri(vscode.Uri.file(path.join(context.extensionPath, 'media', 'message-worker.js')))) - Worker 接收原始
ArrayBuffer或Uint8Array，用TextDecoder解码 +JSON.parse，处理完再发回主线程 - 扩展端可复用同一套逻辑，把 heavy transform 提前在 Node.js 侧完成，只传结果
警惕 CSP 和资源加载拖慢首次通信
WebView 初始化后第一次 postMessage 延迟高，往往不是通信慢，而是 HTML 还没加载完 script、CSS 仍在阻塞渲染，acquireVsCodeApi() 返回 undefined 导致消息被丢弃。
- 确保
webview.html中 JS 入口包裹在document.readyState === 'complete'或window.addEventListener('DOMContentLoaded')内 - CSS 若含
@import url('./theme.css')，必须对theme.css单独调用asWebviewUri，漏掉就会触发 CSP block，控制台报Refused to load resource - 禁用调试器对
internal/modules/cjs/loader.js的拦截——在launch.json的skipFiles加上该路径，否则 Worker 启动被卡住
真正卡吞吐的地方，从来不在「能不能发」，而在「发什么」和「什么时候发」。很多插件把整个 document 对象扔进 postMessage，还纳闷为什么滚动条一动就掉帧——那不是通信问题，是自己在喂 WebView 吃内存垃圾。
