大型文本文件导致VSCode插件卡死，主因是onDidChangeTextDocument未节流、全文解析阻塞主线程；应改用event.contentChanges、防抖、Web Worker、TextDocumentContentProvider流式加载、LSP路径过滤及WeakMap内存管理。
为什么大型文本文件会让插件卡死在 onDidChangeTextDocument
VSCode 插件在监听文档变更时，若未做节流或范围判断，onDidChangeTextDocument 会为每次按键、粘贴、甚至光标移动都触发完整解析——对百万行日志或压缩 JSON 来说，等于每秒执行数十次全文扫描。Node.js 主线程被阻塞，UI 立即冻结。
常见错误现象包括：输入延迟明显、保存后界面假死 2–5 秒、插件进程 CPU 占用飙高至 90%+。
- 不要在回调里直接调用
document.getText()获取全文；改用event.contentChanges只处理变动区域 - 避免在事件中同步执行正则全局匹配（如
/pattern/g.exec(text)），改用流式分块或 Web Worker 预处理 - 对超大文件（>10MB）主动降级：通过
document.uri.fsPath判断后跳过语法分析逻辑 - 设置防抖阈值，例如用
setTimeout延迟 300ms 执行后续操作，合并连续变更
TextDocumentContentProvider 流式加载的正确姿势
想支持“无限大”日志查看？别用 fs.readFile 一次性读进内存。VSCode 的 TextDocumentContentProvider 允许你按需返回内容片段，但必须严格遵守协议：它只在用户滚动到可视区域时才调用 provideTextDocumentContent，且该方法必须是同步的。
容易踩的坑是：在 provideTextDocumentContent 中发起异步请求（如 fetch 或 readFile），导致 VSCode 报错 Unable to load document: promise returned。
- 用
fs.createReadStream+stream.pipeline配合Buffer.toString()截取指定字节范围（注意 UTF-8 多字节边界） - 缓存已读取的区块（如每 1MB 一个缓存项），避免重复 IO
- 在
resolve回调中直接返回字符串，不要 await 异步操作 - 配合
vscode.window.showTextDocument的viewColumn和preserveFocus控制打开行为，防止意外激活编辑器
语言服务器（LSP）对大文件的默认行为怎么关
TypeScript、Python 等语言服务器默认会对所有打开的 .ts、.py 文件启动全量语义分析。当用户误开一个 200MB 的 bundle.js，LSP 会尝试构建 AST 并推导类型——这不仅没意义，还会拖垮整个 Extension Host 进程。
关键不是禁用整个 LSP，而是精准排除无关路径和文件类型。
- 在插件激活时调用
vscode.languages.registerDocumentSemanticTokensProvider前，先检查document.languageId是否在白名单内（如只允许typescript，拒绝javascript） - 通过
vscode.workspace.getConfiguration('typescript').update('preferences.disableSuggestions', true, vscode.ConfigurationTarget.Global)动态关闭建议（注意权限） - 向 LSP 发送
workspace/didChangeConfiguration消息，更新files.exclude规则，让服务端跳过匹配路径 - 监听
vscode.workspace.onDidOpenTextDocument，对超大文件自动设为只读：document.save = () => Promise.resolve()（仅限自定义 provider 场景）
内存泄漏比卡顿更隐蔽：WeakMap 和 Disposables 必须配对用
插件中常把文档对象、装饰器、事件监听器缓存在全局 Map 里，但忘记在文档关闭时清理。VSCode 不会自动 GC 已关闭但仍有引用的 TextDocument 实例——尤其当它被闭包捕获后，内存占用会随打开/关闭文件次数线性增长。
典型表现是：插件运行 2 小时后内存从 120MB 涨到 900MB，重启后回落，但再次缓慢爬升。
- 所有
vscode.window.onDidChangeActiveTextEditor监听器必须用context.subscriptions.push(...)注册，确保插件停用时自动 dispose - 缓存文档相关状态时，优先用
WeakMap<textdocument t></textdocument>而非Map，避免强引用阻止 GC - 使用
vscode.Disposable.from(...)包装手动创建的定时器、WebSocket 或文件 watcher，统一管理生命周期 - 在
deactivate钩子中显式调用context.subscriptions.forEach(d => d.dispose())，不要依赖自动清理
真正难处理的从来不是“怎么读得快”，而是“怎么知道不该读”。大文件场景下，插件的价值不在于强行解析，而在于快速识别上下文意图并主动退让——比如检测到文件 >50MB 且无编辑需求时，直接隐藏格式化按钮、禁用 hover 提示、转为只读流式视图。这些决策点比算法优化更重要，也更容易被忽略。
