鼠标划过卡顿主因是渲染线程被语法分析、文件监视或WebView等后台任务抢占，非hover本身问题；典型表现是悬停延迟弹出或编辑器短暂无响应，需通过禁用项目诊断、限制装饰文件大小、推迟hover延迟等配置优化。
鼠标划过就卡住，大概率不是提示本身的问题，而是渲染线程被抢占——editor.hover.delay 只是表象，真正拖慢的是背后正在跑的语法分析、文件监视或 WebView 渲染。
hover 卡顿的真实原因：不是 hover，是后台在“抢 CPU”
VSCode 的悬浮提示（hover）本身极轻量，但触发时会顺带激活语言服务器、语法装饰器、甚至 Markdown 预览引擎。一旦这些服务正忙（比如 TypeScript 正在全量解析 node_modules，或 Markdown Preview Enhanced 在滚动时重绘大文件），hover 就会卡住半秒以上，光标悬停后延迟弹出，甚至整个编辑器短暂无响应。
- 常见错误现象：
Developer: Open Process Explorer里看到shared-process或某个扩展进程持续占 CPU >40% - 典型场景：打开含 1000+ 行 Markdown 的 README、编辑大型 TS 项目、同时开着 3 个预览窗口
- 别误判为显卡问题——GPU 加速对 hover 延迟影响极小，禁用
--disable-gpu不解决这个
精准关闭 hover 触发链：从 settings.json 入手
不关 hover 功能，只断掉它背后最耗资源的依赖。关键配置必须写进 settings.json，UI 设置界面改了可能不生效。
- 禁用自动 TOC 更新（对大文件是卡顿源）：
"markdown.extension.toc.autoUpdate": false - 限制语法装饰大小（跳过 >100KB 文件的高亮/跳转）：
"markdown.extension.syntax.decorationFileSizeLimit": 100000 - 推迟 hover 弹出时间，避开打字高峰：
"editor.hover.delay": 500（默认 300，加到 500 能躲开很多误触） - 彻底禁用实时预览（如果不用右侧自动刷新）：
"markdown-preview-enhanced.autoPreview": false
语言服务降级：TypeScript 和 Python 是 hover 卡顿主力
TS/JS 的 hover 信息来自 tsserver，Python 来自 Pylance 或 Jedi。它们默认做全量语义分析，一碰 hover 就要算类型、查定义、推导泛型——低配机直接卡死。
- 关掉项目级诊断（最有效）：
"typescript.tsserver.experimental.enableProjectDiagnostics": false - 禁用自动导入扫描：
"typescript.preferences.autoImportFileExcludePatterns": ["**/dist/**", "**/lib/**"] - Python 用户换轻量引擎：
"python.languageServer": "Jedi"（Pylance 功能强但吃资源） - 验证是否生效：打开一个
.ts文件，按Ctrl+Space看补全是否变慢——如果变快了，说明 tsserver 负载确实下来了
扩展冲突排查：hover 卡住时，往往有扩展在“偷偷干活”
很多扩展会在 hover 触发时顺带执行检查：GitLens 查提交记录、ESLint 扫当前行、Auto Rename Tag 同步标签名……叠加起来就是卡顿。
- 先用
Developer: Reload with Extensions Disabled测试——如果 hover 立刻流畅，说明是扩展问题 - 重点禁用：
GitLens（关掉gitlens.hovers.enabled）、ESLint（设"eslint.run": "onType"改为"onSave"）、Auto Import（直接禁用） - 别信扩展描述里的“轻量”——用
Developer: Show Running Extensions看真实内存/CPU 占用，Code Spell Checker在大 Markdown 文件里 hover 时也能吃掉 200MB+
hover 卡顿最难调的地方在于：它不像启动慢那样有明确时间点，也不像 CPU 飙高那样容易被监控捕获。你得在光标悬停那一瞬间，去查 Process Explorer 里哪个进程正在“抢帧”。多数时候，问题不在 hover 设置本身，而在你没关掉的某项后台分析服务。
