VSCode 不支持拖拽文件夹自动重构引用，因其语言服务仅作用于源码语义层而非文件系统层；需手动移动目录、更新配置（如 tsconfig.json paths、构建工具 alias）、重启语言服务并重命名符号，Java 还需人工检查硬编码包名。
VSCode 本身不直接提供“工程目录重构”功能，所谓目录结构调整（比如把 src/utils 搬到 libs/core、重命名整个包路径、调整 TypeScript 的 baseUrl 和 paths 映射）必须靠手动操作 + 配置修正 + 符号引用联动更新来完成。纯靠 F2 重命名或右键 Refactor 是无效的——它只处理代码内符号，不碰文件系统层级。
为什么 VSCode 不支持拖拽文件夹自动重构引用
语言服务（如 TypeScript Server 或 JDT.LS）的工作边界在源码语义层，而非文件系统层。当你在资源管理器里拖动一个 utils 文件夹时，VSCode 只会移动物理路径，不会自动：
- 修改所有 import 语句里的相对/别名路径
- 更新 tsconfig.json 或 jsconfig.json 中的 "paths" 配置
- 修正 Webpack/Vite 的 resolve.alias
- 同步修改 Java 的 module-info.java 或 Spring 的 XML 配置中 class 全限定名引用
这些属于跨工具链的耦合操作，VSCode 默认不介入，也不具备通用解析能力。
安全重构目录结构的三步实操法
真正能落地的目录重构，得靠组合动作：
- 先用 VSCode 的
Find in Files（Ctrl+Shift+F）全局搜索旧路径字符串，例如"@utils/"或../utils，确认所有引用位置 - 手动移动文件夹后，立刻更新配置文件：
tsconfig.json中的"paths"、vite.config.ts中的resolve.alias、Java 项目的pom.xml或build.gradle中的 sourceSets - 重启 TS/JS 语言服务（
Ctrl+Shift+P→TypeScript: Restart TS server），再对关键导出变量/类执行F2重命名——此时新路径已生效，符号引用才能被正确识别并批量更新
Java 工程中移动 package 的特殊风险
Java 的目录即包结构，移动 com.example.service 到 com.example.core.service 时，以下地方极易漏改：
-
@ComponentScan或@SpringBootApplication的basePackages参数 - XML 配置中
<bean class="com.example.service.UserService">这类硬编码全限定名 - 反射调用：
Class.forName("com.example.service.UserService") - Lombok 的
@Builder或@Data注解生成的内部类路径（虽不显式写，但编译后字节码含旧包名）
这类引用无法被语言服务静态分析覆盖，必须人工 grep 或 IDE 全局搜索 com.example.service 字符串，否则运行时报 NoClassDefFoundError 或 ClassNotFoundException。
别依赖插件自动补全路径映射
有些插件（如 Path Intellisense）能提示路径补全，但它不参与重构决策；另一些插件（如 Auto Rename Tag）只管 HTML 标签，和模块路径无关。真正起作用的是你配置的 compilerOptions.baseUrl 和 paths——它们决定了语言服务能否把 @utils/foo 解析成 src/utils/foo.ts。如果移动后没同步改这里，F2 重命名会失败，因为符号表根本找不到定义。
最常被忽略的一点：路径映射变更后，必须关闭再重开文件，或执行 Developer: Reload Window，否则缓存的旧解析结果还在，重命名只会改当前文件，跨文件引用不动。
