VSCode插件不直接解析路径，但Path Intellisense、ESLint等行为依赖jsconfig.json/tsconfig.json中的baseUrl和paths配置；配置缺失、路径错误或工作区未正确打开（需File > Open Folder）会导致补全失效、跳转中断、类型报错。
VSCode插件本身不直接参与路径解析，但多个关键插件（如 Path Intellisense、ESLint、Prettier）的正确行为高度依赖于 VSCode 对当前工作区根路径、jsconfig.json/tsconfig.json 中 baseUrl 和 paths 的识别结果。路径没对，补全就错、跳转就断、类型检查就报红。
Path Intellisense 的路径补全为什么有时失效
它不是靠猜，而是读取当前打开的 jsconfig.json 或 tsconfig.json 中的 compilerOptions.baseUrl 和 compilerOptions.paths 来做 alias 映射。如果这些配置缺失、路径写错，或工作区没正确加载（比如用文件夹而非工作区方式打开项目），补全就会退化为纯文件系统扫描。
- 确保工作区是通过
File > Open Folder...打开的，而不是单个文件 —— 否则jsconfig.json可能不被识别 -
baseUrl必须是相对路径（如"./"），不能是绝对路径；paths的 key 末尾需带/*，value 数组里每个路径也必须以/*结尾 - 插件默认只在
.js/.ts文件中激活；若要在.vue或.jsx中启用，需在设置中手动添加："path-intellisense.mappings"或修改files.associations
ESLint + Prettier 路径解析冲突的典型表现
当你看到 ESLint: Definition for rule 'xxx' was not found 或 Prettier 格式化后 import 路径被重写成相对路径（而你想要 alias），本质是 ESLint 和 Prettier 加载配置时用了不同工作目录，或没正确继承 jsconfig.json 的路径别名。
- ESLint 必须运行在项目根目录下才能读到
.eslintrc.js和jsconfig.json；如果用多根工作区，需确认 ESLint 插件已为每个文件夹启用 -
prettier-vscode默认不理解paths别名，它只按文件系统路径格式化；要保留@/components/Button这类写法，得配合eslint-plugin-import的import/resolver配置，并关闭 Prettier 对 import 的重写（如禁用prettier/import-order） - 常见错误：把
jsconfig.json放在子包（如packages/ui）里，但根目录的 ESLint 配置没指定root: true，导致它向上查找时忽略子包配置
如何验证当前 VSCode 实际使用的路径上下文
别猜，直接看 VSCode 自己认的是什么。很多问题其实只是“它以为的根目录”和“你以为的根目录”不一致。
- 命令面板输入
Developer: Show Running Extensions，查看Path Intellisense和ESLint插件的状态栏提示，它们通常会显示当前生效的配置路径 - 在任意 JS/TS 文件中，右键选择
Go to Type Definition（不是Go to Definition），如果跳转失败，大概率是jsconfig.json的baseUrl没生效，或node_modules类型声明没被识别 - 终端里执行
code --status，输出中会列出当前窗口的Working Directory和已加载的扩展路径 —— 这是最权威的“VSCode 当前视角”
路径解析不是静态配置，而是 VSCode 启动时动态扫描、逐层合并的结果。工作区结构、配置文件位置、插件加载顺序，三者稍有错位，alias 就会断、跳转就失效、格式化就乱套。最稳妥的做法：每次怀疑路径问题，先用 code --status 确认工作目录，再查 jsconfig.json 是否在该目录下，最后看插件是否声明了对该配置的依赖。
