悬停提示卡顿或闪退主因是LSP冷启动时被editor.hover.delay=0强制触发，导致服务未就绪即发请求；合理值为200–400ms，既避抖动又防误触；Pylance/Volar等扩展hover需单独配置或排除node_modules等路径优化。
为什么悬停提示卡顿或闪退
悬停卡顿不是配置写错了，而是语言服务器（LSP）冷启动时被强制触发。比如设 editor.hover.delay 为 0，VSCode 会立刻发请求，但 Pylance、Volar 或 TypeScript Server 还没加载完，结果就是空白框闪一下、界面卡住 2～3 秒，甚至触发渲染异常。
常见表现包括：
- 悬停后提示框延迟出现，且内容为空或只有基础类型（如
string） - 状态栏右下角显示 “Loading…” 或语言服务器图标持续旋转
- 大型项目首次打开时，连续悬停多个变量，响应越来越慢
调 editor.hover.delay 到多少才合理
默认值是 500 毫秒，但多数人实际体验更顺手的是 200～400 毫秒：既避开 LSP 刚唤醒时的抖动，又比默认快，还不容易误触。
别设成 0 —— 它不等于“立即”，只是跳过等待直接发请求，反而暴露服务瓶颈。实测中，小 Python 脚本 + Pylance 缓存热的情况下设 0 才可能稳；TypeScript monorepo 里设 0 基本等于主动卡自己。
改完不用重启 VSCode，但旧提示可能还缓存着，需悬停新代码行才生效。
语言服务器层的延迟怎么控
editor.hover.delay 只影响编辑器原生层，对 Pylance、Volar、Rust Analyzer 等扩展自带的 hover 行为基本无效。它们用各自策略控制触发时机和缓存。
能做的有限但关键：
- Volar v1.10+ 支持
volar.hover.delay，可单独设 - Rust Analyzer 不暴露 delay 配置，但关掉
rust-analyzer.hoverActions.enable能减少额外动作开销 - Pylance 没公开 hover 延迟项，最有效的是排除无用路径：
"files.watcherExclude": { "**/node_modules/**": true, "**/dist/**": true }
真正拖慢 hover 的“伪 hover”有哪些
很多你以为是 hover 卡，其实是颜色预览、Git Blame、终端链接这些“长得像 hover”的独立通道在抢资源：
- 悬停
#ff0000弹调色板 → 关colorDecorators.enabled - 悬停
alice@abc123 2024-03-15显示 Git 提交信息 → 关gitlens.showCurrentLineBlame和gitlens.codeLens.enabled - 终端里悬停路径变蓝 → 关
terminal.integrated.showLinkHover - HTML 中悬停 DOM API 跳 MDN → 关
html.suggest.html5和css.mdnsuggest
这些功能互不干扰，但叠加后会让 hover 响应明显变沉。禁用后不影响语法校验、补全或运行，只是少一层视觉反馈。
hover 性能问题最难搞的地方在于：你看到的每个提示框，背后可能来自编辑器、LSP、扩展三套不同系统，而 VSCode 不提供 hover 来源追溯功能——只能靠逐个关配置 + 重启验证，才能摸清哪一层在拖后腿。
