Path Intellisense 是开箱即用的 JS 全路径补全方案，仅补全字面量路径（如 import、require 中引号内字符串），不解析运行时拼接；依赖语言模式为 JS/TS，通过监听语法上下文自动扫描工作区生成候选路径，并支持别名静态映射。
Path Intellisense 是目前最直接、开箱即用的 JS 全路径跟踪辅助方案，不需要写代码、不依赖项目配置，但必须理解它只补全字面量路径，不解析运行时拼接。
Path Intellisense 如何识别 JS 中的 import/require 路径
它监听 import、require、define（AMD）等语句中引号内的字符串字面量，自动扫描当前工作区文件结构生成候选列表。
- 支持 ESM：
import { foo } from "./utils/helper.js"—— 输入"./后立刻提示子目录和文件 - 支持 CommonJS：
const config = require("../config/index.json")—— 输入"../会向上遍历并列出父级可选路径 - 不支持动态拼接：
require("./" + name + ".js")或import(`./${module}.ts`)完全无响应 - 语言模式必须为
JavaScript或TypeScript；若文件被识别为Plain Text，补全不会触发
为什么 vscode.window.activeTextEditor.document.fileName 不适合做“路径跟踪”
这个 API 只返回当前打开文件的绝对路径字符串，属于编辑器状态快照，不是路径解析或补全能力。它常被误用于插件开发中“读取当前文件内容”，但和“JS 代码中路径的智能跟踪”完全无关。
- 它无法感知
import语句上下文，也不参与路径补全逻辑 - 在插件里调用它需要
vscode模块，且只能在激活态扩展中运行，对普通 JS 开发者无意义 - 常见误用：试图用它替代
path.resolve()或import.meta.url做模块解析 —— 这两类行为发生在 Node.js 或浏览器运行时，VSCode 编辑器层不参与
如何让路径补全支持别名（如 @/components）
靠 path-intellisense.mappings 配置实现，本质是静态字符串映射，不是真正的模块解析器。
- 在
settings.json中添加："path-intellisense.mappings": { "@": "${workspaceFolder}/src", "#": "${workspaceFolder}/types" } - 输入
@/c就能补全到@/components/Button.vue，但注意：这不会校验tsconfig.json或jsconfig.json中的compilerOptions.paths - 如果项目同时用了 Vite 别名和 Webpack 别名，该配置只影响编辑器补全，不影响实际构建 —— 构建失败仍需检查对应工具配置
- Windows 用户要注意：
${workspaceFolder}展开后是反斜杠路径，但插件默认输出正斜杠，兼容性没问题
真正容易被忽略的是：Path Intellisense 的补全结果只是字符串插入，它不验证目标文件是否存在、是否可导入、是否类型匹配。如果你重构了 src/utils 为 src/lib，它依然会补全旧路径——得靠 ESLint 的 import/no-unresolved 规则或 TypeScript 的路径检查来兜底。
