关键在于让本地tsc深度介入：启用tsconfig.json的strict模式与noemit，确保vscode使用workspace版本typescript，并同步配置paths与打包工具的alias，重启ts服务器验证生效。
VSCode 默认的 TypeScript 支持只是基础层，真正提升类型安全的关键不在插件数量，而在配置是否让 tsc 语言服务深度介入编辑流程——所有类型推导、路径别名解析、strict 检查生效与否，都取决于 tsconfig.json 和编辑器行为是否对齐。
确认 VSCode 正在使用项目本地的 TypeScript 版本
类型提示不准、跳转失败、any 泛滥，90% 源于 VSCode 没用上你 node_modules 里的 typescript。它可能正用着内置旧版或全局安装的版本。
- 打开任意
.ts文件，看右下角状态栏是否显示 TypeScript 版本号；没显示或显示 “Built-in” 就要干预 - 点击版本号 → 选 “Use Workspace Version”（不是 “Use VS Code’s Version”）
- 如果选项灰掉，说明项目没装
typescript：运行npm install --save-dev typescript，再重启 TS 服务器（Ctrl+Shift+P→TypeScript: Restart TS server） - 验证是否生效：在
tsconfig.json中临时加个非法字段（如"xxx": true），保存后看 VSCode 是否报错 —— 报了就说明它真在读你的配置
tsconfig.json 必须启用 strict 模式且 noEmit
strict: true 不是可选项，它是类型安全的总开关。关掉它，noImplicitAny、strictNullChecks、noImplicitThis 全部失效，VSCode 的类型检查形同虚设。
- 生成后立刻检查
tsconfig.json中"strict": true是否存在；若被注释或为false，手动改回true - 务必设置
"noEmit": true：VSCode 只做类型检查，不生成 JS；编译交给vite build或webpack，避免编辑器和构建工具输出不一致 - 不要依赖
"skipLibCheck": true来掩盖问题——它跳过@types检查，可能导致类型定义缺失却无提示 - 若用路径别名（如
@/utils），必须配"baseUrl": "./"和"paths"，否则 VSCode 无法解析导入、补全失效
.vscode/settings.json 要强制保存时修复 ESLint + 整理导入
类型安全不只是“不报错”，更是“写对”。ESLint 在保存时自动修复能拦截大量低级错误，而导入整理能避免循环引用和路径混乱。
- 在项目根目录的
.vscode/settings.json中启用："editor.formatOnSave": true、"source.organizeImports": true -
"editor.codeActionsOnSave"必须包含："source.fixAll.eslint": "explicit"（不是true，否则会覆盖用户手动选择） - 确保
eslint插件已安装，并项目中有.eslintrc.cjs或eslintConfig字段；缺少规则文件时，fixAll不会生效 - 禁用
javascript.validate.enable（设为false）：避免 JS 文件触发旧版校验逻辑，干扰 TS 类型推导
路径别名和模块解析必须匹配打包工具
VSCode 能识别 @/components 并提供补全，不代表运行时能加载它。如果 tsconfig.json 的 paths 和 Vite/Webpack 的 resolve.alias 不一致，开发时一切正常，构建时报错才暴露问题。
-
tsconfig.json中"moduleResolution": "bundler"是现代项目的标配，它让 TS 语言服务模拟打包器行为 - Webpack 用户需同步配置
resolve.alias；Vite 用户需在vite.config.ts中配resolve.alias，值必须与tsconfig.json的paths完全一致 - 别名路径末尾带
/*（如"@/*": ["src/*"]）不能省略，否则 VSCode 无法展开子路径补全 - 修改别名后，必须重启 TS 服务器，否则旧缓存会导致补全失效
最容易被忽略的是 noEmit 和 moduleResolution: "bundler" 的组合——前者让 VSCode 专注检查，后者让它检查得准；两者缺一，类型提示就可能在开发时“看起来对”，上线后却崩。
