VS Code 对 TS/js 支持开箱即用，但需正确配置 tsconfig.json（含 include、baseUrl、strict）、jsconfig.json（checkJs、typeAcquisition）及 settings.json（auto imports、suggestionActions 等）才能保障类型安全与智能提示准确。
VS Code 对 typescript 和 javaScript 的支持开箱即用，不需要额外安装插件就能获得基础语法高亮、智能提示和错误检查——但要真正发挥其生产力，关键在于理解哪些配置是必须的、哪些是容易误配的。
为什么 tsconfig.json 是 TypeScript 项目的核心
VS Code 的 TypeScript 语言服务完全依赖项目根目录下的 tsconfig.json 来决定类型检查范围、编译目标、模块解析方式等。没有它，VS Code 只会以默认宽松策略处理文件，导致类型提示不准、any 泛滥、路径别名失效等问题。
- 必须在项目根目录手动创建
tsconfig.json，哪怕只写{"compilerOptions": {}}也能激活完整服务 -
"include"字段要明确列出源码路径（如["src/**/*"]），否则node_modules或dist下的 .ts 文件可能被意外纳入检查 - 若使用
paths别名，务必同时设置"baseUrl": "."，否则 VS Code 无法解析import utils from "@/utils" - 开启
"strict": true后，noImplicitAny、strictNullChecks等子选项才真正生效，仅设strict不够
javascript 项目如何启用类型检查
纯 JavaScript 项目也能享受 TypeScript 的类型推导能力，但需主动启用，否则所有 const x = [] 都会被视为 any[]，失去类型安全。
- 在 JS 文件顶部添加
// @ts-check单行注释，即可对当前文件启用类型检查 - 在项目根目录创建
jsconfig.json并写入{"checkJs": true}，全局启用（效果等同于每个 JS 文件都加了@ts-check） -
jsconfig.json中的"allowSyntheticDefaultImports"和"moduleResolution"必须与实际打包器（如 webpack/vite）保持一致，否则 VS Code 提示的“无法找到模块”可能和运行时行为不一致 - 遇到
Cannot find module 'xxx'错误时，优先检查jsconfig.json是否遗漏"typeAcquisition": {"enable": true}—— 这会自动下载@types包定义
settings.json 中最值得调整的几项
用户级或工作区级的 settings.json 能覆盖默认行为，但多数人只改了无关紧要的项，反而忽略了影响开发体验的关键配置。
立即学习“Java免费学习笔记（深入）”；
-
"typescript.preferences.includePackageJsonAutoImports": "auto"：启用后，在import行输入时自动补全package.json中已安装的包，避免手敲拼错 -
"javascript.suggestionActions.enabled": true：JS 文件中按Ctrl+Space时显示“添加类型注解”建议（如把function foo(x) {}补全为function foo(x: number): void {}） -
"typescript.preferences.useAliasesForRenames": true：重命名一个导入名时，自动同步更新所有使用该别名的位置（包括字符串中的路径），避免漏改 - 禁用
"typescript.preferences.quoteStyle": "double"类似格式化配置——它们由 Prettier 或 ESLint 管控更可靠，VS Code 内置格式化器容易与其他工具冲突
真正麻烦的从来不是配置本身，而是不同配置之间的隐式依赖：比如 jsconfig.json 里的 baseUrl 必须和 tsconfig.json 一致，否则路径跳转在 TS 文件里正常、在 JS 文件里就失败；又比如 node_modules/@types 的存在与否，会直接决定 VS Code 是否能识别 express.Request 这类类型——这些细节不报错，但会让智能提示突然“变笨”。