TypeScript 悬停不显示类型通常因 tsserver 未启动或配置错误：检查 tsconfig.json 是否存在、右下角 TypeScript 版本是否启用、compilerOptions（如 skipLibCheck）是否合理，并查看开发者工具中 tsserver 报错。
鼠标悬停不显示 TS 类型，先确认 TypeScript 服务是否启用
VSCode 默认依赖内置的 TypeScript 语言服务提供类型提示，如果悬停没反应，大概率不是设置问题，而是 tsserver 没跑起来或加载失败。
- 打开命令面板（
Ctrl+Shift+P/Cmd+Shift+P），输入并执行Developer: Toggle Developer Tools，在 Console 里搜tsserver或TS Server，看有没有报错（比如找不到typescript包、版本冲突） - 检查当前工作区是否在 TS 项目中：必须存在
tsconfig.json，且文件后缀是.ts或.tsx；纯.js文件即使有 JSDoc 也不会触发完整 TS 类型推导 - 右下角状态栏查看 TypeScript 版本号 —— 如果显示 “TypeScript 4.9.5 (Workspace)” 说明已启用；若显示 “JavaScript” 或空白，点它手动切换到 TS
tsconfig.json 配置影响悬停内容的完整性
悬停看到的类型信息深度，直接受 compilerOptions 控制。默认配置下可能只显示简化类型（如 any），而非实际推导出的完整结构。
-
"noImplicitAny": true不影响悬停，但能暴露未标注类型的位置，间接帮你定位为什么某处悬停只显示any -
"skipLibCheck": false（默认）才能让悬停穿透到 node_modules 里的声明文件；设为true后，第三方库类型可能变成any或不完整 - 如果用
declare module手动补全类型，确保该文件被include或typeRoots覆盖，否则悬停看不到自定义类型
悬停显示“Loading…” 卡住或延迟高
这不是 UI 冻结，而是 tsserver 在解析大型项目或复杂类型时的真实耗时。尤其在含大量泛型、条件类型、递归类型的代码中很常见。
- 检查
node_modules是否被纳入 TS 监控：在tsconfig.json中明确"exclude": ["node_modules"]（虽然默认排除，但某些 workspace 配置会覆盖） - VSCode 设置里搜索
typescript.preferences.includePackageJsonAutoImports，设为"auto"或"off"，避免自动导入分析拖慢服务 - 大项目可尝试关闭
typescript.suggest.autoImports，减少后台类型补全压力，对悬停响应速度有明显改善
JS 文件里想看类似 TS 的悬停，得靠 JSDoc + checkJs
纯 JS 项目无法直接享受 TS 类型系统，但通过轻量标记也能获得近似效果，前提是启用 checkJs 并写对 JSDoc。
- 在
jsconfig.json或tsconfig.json（用于 JS 项目）中开启"checkJs": true - JSDoc 注释必须紧贴变量/函数上方，且语法要准：
/** @type {import('./types').User} */可以，// @type {...}不行 - 注意路径别名（
@/）在 JSDoc 里不生效，必须写相对路径或已配置的paths映射（需配合baseUrl） - 悬停时看到的类型是“校验后推导结果”，不是运行时值 —— 所以
/** @type {string} */ let x = 123悬停仍显示string，但编辑器会标红
类型推导不是魔法，它卡在哪儿，往往就暴露了项目配置的盲区。比如悬停里突然出现 any，大概率是某个 index.d.ts 没被识别，或者泛型链断在了某一层 —— 这时候别调设置，先看 DevTools 里的 tsserver 日志。
