vscode本身不提供语义解析能力，仅展示物理路径结构；深度解析依赖插件结合文件名、内容特征及项目约定识别模块边界、分组标注，并支持自定义规则实现语义化目录视图与交互式依赖图谱。
VSCode 本身不提供代码文件树的“语义解析”能力，它只展示物理路径结构。所谓“深度解析目录”，实际依赖插件对项目逻辑结构的理解——比如识别 src/api/ 下是请求层、src/store/ 是状态管理、哪些是测试文件、哪些是配置入口。这类插件不是简单列文件，而是结合文件名、内容特征、项目约定（如 Vite/Next.js 结构）做分组和标注。
为什么默认资源管理器看不出“模块边界”
VSCode 内置的资源管理器只读取文件系统层级，不分析代码内容或项目配置。它无法区分 utils.ts 是通用工具还是业务专属工具，也无法识别 index.ts 是导出入口还是普通模块。这种“扁平化”视图在中大型项目里容易迷失上下文。
- 真实问题：你在
src/pages/UserDetail里改一个 hook，却不知道它被哪些页面或组件引用 - 典型盲区：
constants.ts被散落在十几个目录里，资源管理器只显示“一堆同名文件”，不聚类也不标用途 - 根本限制：没有插件介入时，VSCode 不会扫描
import语句或export声明来反推依赖关系
Explorer Enhancer：按语义分组而非按路径排序
这个插件能基于文件内容自动给目录节点打标签，比如把所有含 useQuery 的 .ts 文件归为“React Query Hook”，把匹配 /store/.*.ts$/ 的文件标为“Pinia Store”。它不改变物理结构，但重绘侧边栏的视觉逻辑。
- 启用后右键文件 → “Group by semantic type”，会弹出分类菜单（API / Component / Test / Config）
- 支持自定义规则：在
.explorer-enhancer.json中写正则，例如"test": ".*\.(spec|test)\.(ts|js)$" - 注意：首次加载会扫描整个工作区，大项目可能卡顿 2–3 秒，建议关闭
"scanOnStartup"改为手动触发
Project Viewer：可视化依赖图谱替代树形列表
如果你真正需要的是“哪个文件依赖了 src/lib/crypto.ts”，Project Viewer 比任何文件夹分组都直接。它用 esbuild 解析 AST，生成可交互的依赖图，点击节点就能跳转到具体 import 行。
- 命令面板输入
Project Viewer: Show Dependency Graph启动 - 图中节点大小 = 该文件被引用次数，颜色深浅 = 修改频率（需开启 Git 集成）
- ⚠️ 坑点：不支持动态
import()或 webpack require.context，这类依赖会被漏掉 - 性能提示：首次构建图谱耗时与
node_modules大小正相关，建议在settings.json中配置"projectViewer.exclude": ["**/node_modules/**", "**/dist/**"]
Code Outline + 自定义大纲提供器
真正“深度解析”的终点，其实是把目录理解升级为大纲理解。VSCode 的大纲视图（Ctrl+Shift+O）默认只显示函数/类，但通过插件注册 DocumentSymbolProvider，能让它识别领域概念——比如把 definePageMeta 块当作“路由元信息节点”，把 export default defineComponent 当作“Vue 页面根节点”。
- 实现方式：插件在
activationEvents中声明"onLanguage:vue"，然后在activate函数里调用vscode.languages.registerDocumentSymbolProvider - 效果示例：打开
pages/user/index.vue，大纲里出现Route Meta、Setup Script、Template Slots三个折叠区块，而非只有setup()函数 - 兼容性注意：该 API 要求 VSCode 版本 ≥ 1.70，旧版会静默降级为默认大纲
复杂点在于，没有插件能 100% 理解你的项目约定——比如你把接口定义全放在 types/ 但实际调用都在 composables/，就必须手动配一条 link 规则，否则依赖图里这两块永远断开。这恰恰说明，“深度解析”的本质不是自动化，而是把隐式约定显式编码进插件配置里。
