Hover提示延迟由editor.hover.delay控制，非网络问题；默认500毫秒，设为200～300更平衡；需检查工作区/语言专属设置覆盖、插件劫持及语言服务器负载（如TS初始化卡顿、files.watcherExclude未配置）。
Hover提示延迟由editor.hover.delay控制，不是网络问题
VSCode悬浮提示（鼠标悬停显示类型/文档）卡顿，和插件市场慢、代码补全慢是不同链路——它不走网络请求，纯本地语言服务响应，瓶颈在editor.hover.delay默认值和语言服务器负载。这个值默认是500毫秒，意味着你停住鼠标半秒后才开始查类型信息，不是“没反应”，而是“等得久”。
- 设为0可实现鼠标悬停即触发，但会增加CPU压力，尤其在大型TS/JS项目中可能拖慢编辑器整体响应
- 设为200～300是更稳妥的平衡点：比默认快一倍，又不至于让
Code Helper (Renderer)进程频繁飙高 - 该设置支持按语言单独配置，比如只对Python加快：
python.editor.hover.delay - 改完必须重启VSCode或重载窗口（Ctrl+Shift+P →
Developer: Reload Window），热更新不生效
为什么改了hover.delay还是没变快？检查三处覆盖
常见失效不是配置错，而是被更高优先级设置覆盖。VSCode的hover行为由用户设置、工作区设置、语言专属设置三层叠加，且部分插件会悄悄重写。
- 先查项目根目录是否存在
.vscode/settings.json，里面若有editor.hover.delay，它会直接覆盖全局设置 - 再搜
javascript.editor.hover.delay这类语言前缀配置——如果当前文件是.ts，VSCode只认typescript.editor.hover.delay，无视通用项 - 禁用
ESLint、TypeScript Hero、Copilot等插件测试，它们可能劫持hover provider链路，导致延迟逻辑被绕过
Hover卡顿真正根源常是语言服务器本身
调低editor.hover.delay只是让卡顿“提前暴露”。如果你悬停时状态栏右下角反复出现TypeScript initializing…或loading...，说明不是VSCode界面慢，而是TS Server解析卡住。
- 大项目中启用
typescript.preferences.includePackageJsonAutoImports会显著拖慢hover响应，建议关掉 - Python用户注意
Pylance的python.analysis.extraPaths若指向巨量源码目录，hover时会同步扫描，应精简路径 - 强制重启语言服务：Ctrl+Shift+P → 输入
Developer: Restart TS Server（TS/JS）或Python: Restart Language Server - 观察终端输出：启用
typescript.tsserver.log为verbose，日志里出现getQuickInfo耗时超800ms，基本可定位到具体符号解析瓶颈
别忽略文件监视器对hover的隐性影响
很多人只优化hover参数，却忘了VSCode的hover依赖实时文件状态——如果files.watcherExclude没配好，inotify句柄耗尽后，整个语言服务会退化为轮询模式，hover查询会排队等待文件系统反馈。
- 必须在项目根目录
.vscode/settings.json中配置，用户级设置无效 - 至少包含：
"**/node_modules/**": true、"**/venv/**": true、"**/.git/**": true、"**/__pycache__/**": true - 改完后务必关闭并重新打开该工作区，否则watcher不会重建，hover依然卡顿
- Linux/macOS上可用
cat /proc/sys/fs/inotify/max_user_watches确认是否已达上限（推荐设为524288）
dist/目录扫完，或是Pylance正在同步分析你误加进extraPaths的整个node_modules。参数调得再激进，底层链路不通，也只是让“等待”从半秒变成一秒。 
