vscode不会自动更新类型定义文件，它不监听.d.ts变化或外部类型源变更；所谓“自动更新”实为语言服务在保存文件、重启ts服务器、修改tsconfig.json或重载窗口时被动响应。
VSCode 不会自动缓存更新类型定义文件——它不监听 .d.ts 文件内容变化，也不感知外部类型源（如 @types 包升级、openapi.json 变更或 tsconfig.json 中 include 路径调整）；所谓“自动更新”只是语言服务在特定触发点重新加载并解析类型，本质是被动响应，不是持续同步。
为什么改了 types/index.d.ts，VSCode 还提示旧类型？
因为 TypeScript 语言服务（Volar 或内置 TS 插件）不会实时 watch 所有 .d.ts 文件。它只在以下有限时机重新构建类型图：
- 保存一个被
tsconfig.jsoninclude覆盖的.ts或.d.ts文件（但仅限该文件及其直接依赖） - 手动执行
Developer: Restart Language Server（全量重载，最可靠） - 修改并保存
tsconfig.json（触发配置重读，会刷新所有包含路径） - 重载窗口（
Developer: Reload Window），等价于重启 Volar/TS 服务
如果你只是编辑了 types/foo.d.ts 但没保存，或该文件不在 tsconfig.json 的 include 列表里，VSCode 就完全忽略它——连语法高亮都可能失效。
tsconfig.json 的 include 和 files 配置差异直接影响类型可见性
这两项决定哪些文件参与类型检查和补全，但行为不同：
-
files：显式列出所有要纳入编译和类型服务的文件，**不支持 glob**；漏写一个.d.ts，它就彻底不可见 -
include：支持**/*.d.ts等通配符，但**只扫描已存在文件**；新增types/bar.d.ts后，必须至少保存一次任意被 include 的文件，或重启语言服务，才能被识别 -
exclude优先级高于include；常见陷阱是node_modules被排除后，@types包里的声明也失效（应确保"node_modules/**/*"不在exclude中）
建议对类型声明目录统一用 include: ["types/**/*.d.ts"]，避免零散 files 维护遗漏。
Volar 对 defineProps 和 defineEmits 类型更新最敏感，但也最易卡住
在 <script setup lang="ts"></script> 中修改 defineProps 接口后不生效，大概率不是代码问题，而是 Volar 缓存未刷新：
- 确认
.vscode/settings.json已禁用 Vetur："vetur.validation.template": false（否则双插件冲突） - 检查
defineProps是否用了内联类型（如defineProps()）——这类写法更新最及时；若引用外部interface，必须确保该 interface 所在文件被tsconfig.json正确 include - 不要依赖“保存即更新”：哪怕改了
props.ts，也需手动触发Restart Language Server或切换到另一个.vue文件再切回来，强制 Volar 重推上下文
嵌套过深（如 4 层以上泛型推导）或含动态 key 的 Record<string unknown></string> 类型，Volar 可能降级为 any 并缓存该结果，此时重启是唯一解。
第三方类型包（@types/xxx）升级后 VSCode 无反应？
npm 安装新版本 @types 后，VSCode 默认不会自动拉取新声明——它只认当前 node_modules/@types/xxx 下已解析的文件结构，且缓存强：
- 删除
node_modules/.cache/typescript/目录（TS 编译器缓存） - 执行
Developer: Restart Language Server（关键！否则仍读旧缓存） - 检查
package.json中是否误加了"resolutions"锁死旧版@types - 若用 pnpm，确认
pnpm store未复用旧类型包；可运行pnpm store prune清理
真正“自动”的只有 tsc --watch 模式下的增量编译，但那不等于 VSCode 编辑器内的实时补全——后者始终滞后于编译器状态。
类型缓存更新不是靠时间或文件系统事件驱动，而是靠明确的触发点；任何期待“改完就立刻生效”的想法，都会掉进 VSCode 类型服务的设计边界里。最稳的操作永远是：改完 → 保存相关文件 → 手动重启语言服务。
