符号大纲树解析慢，90%是插件拖后腿；需用code --disable-extensions验证，重点关注GitLens、Copilot等监听documentSymbol的扩展，并通过Developer: Show Running Extensions和Process Explorer定位高CPU或内存占用插件。
符号大纲树解析慢，先确认是不是插件在拖后腿
VSCode 的符号大纲树（Outline view）卡顿，90% 不是语言服务本身慢，而是某个插件在后台反复触发、重绘或劫持符号解析事件。直接验证：终端执行 code --disable-extensions，打开同一文件，展开大纲树。如果秒开、滚动顺滑、节点可折叠/跳转，问题就锁定在扩展层——不是 TypeScript 或 Python 语言服务器慢，是某个插件在它上面加了额外监听或装饰逻辑。
重点关注这几类插件的 activationEvents 和状态
运行 Developer: Show Running Extensions，盯住三列：Activation Time、Status、CPU。符号解析卡顿往往来自“安静但高负载”的插件：
-
gitlens：默认开启gitlens.codeLens.enabled和符号级 blame，每次大纲刷新都触发 Git 查询；关掉它或设"gitlens.codeLens.enabled": false -
eamodio.gitlens、ms-python.python、rust-lang.rust-analyzer这类带"activationEvents": ["*"]或"onLanguage:python"的插件，哪怕没显式操作，也会在文件加载时预热符号索引 -
vscode-icons或主题类插件：部分版本会在大纲节点渲染时同步请求图标资源，阻塞主线程；状态栏若显示 “Activating…” 卡住 >500ms，基本就是它 -
tabnine、copilot：它们不直接处理大纲，但会 hooktextDocument/documentSymbol请求，叠加响应延迟；禁用后对比大纲首次展开耗时，常能降下 300–800ms
别急着禁用，先调 settings.json 控制符号相关行为
很多插件的“重”来自默认全量扫描，改配置比卸载更安全、见效更快：
- 关掉非必要符号装饰：
"editor.codeLens": false（大纲树本身不依赖 CodeLens，但某些插件会把它和 Outline 绑定渲染） - 限制语言服务器范围：
"typescript.preferences.includePackageJsonAutoImports": "auto"，避免 TSServer 启动时扫遍node_modules/@types - 排除干扰目录：
"files.watcherExclude"必须包含"**/node_modules/**"和"**/dist/**"，否则符号解析器会被大量无关文件变更事件打乱节奏 - 禁用大纲内联预览：
"outline.showInExplorer": false（这个设置不影响 Outline view 本身，但能防止 Explorer 视图和 Outline 共享同一套低效渲染路径）
查不到具体插件？用 Process Explorer 看 RSS 和 CPU 持续占用
运行 Developer: Open Process Explorer，展开 extensionHost 节点，排序看 RSS（内存）和 CPU 列。符号解析卡顿时，注意这些信号：
- 某个插件 RSS 稳定在 400MB+，且你没打开任何大文件 → 它在后台缓存符号树，但没释放
-
CPU柱状图在你点击大纲节点瞬间突然拉高，持续 >200ms → 它在响应onDidExpandItem或类似事件 - 禁用插件后 RSS 不下降 → 必须运行
Developer: Restart Extension Host，否则残留对象还在占内存 - 多个插件同时对
textDocument/documentSymbol响应（比如prettier+eslint+copilot），叠加延迟会指数级上升，单看一个都不超时，合起来就卡
真正难搞的不是报错的插件，是那个 Status 显示 Activated、Startup Time 只有 12ms、却在每次大纲折叠/展开时偷偷调用 fs.statSync 的插件——它不会出现在错误日志里，只能靠 Process Explorer 的实时采样抓到。
