正确做法是使用language support for java™插件的「移动类」重构（move class）：右键类名→refactor→move，自动更新package声明、import语句、文件路径及符号索引；手动拖动文件必然导致编译失败。
VSCode里改Java包名，别手动拖文件
直接在资源管理器里拖动 .java 文件改包路径，几乎必然出错。VSCode原生不感知Java的包结构语义，拖完只是移动了文件，package 声明、import 语句、Maven/Gradle模块依赖、甚至IDE内部符号索引全都不同步——编译失败是常态，不是意外。
正确做法只有一条：用 Language Support for Java™ 插件提供的「移动类」重构（Move Class），它才是唯一能联动更新全部上下文的操作。
- 右键点击类名（不是文件名，不是包声明行），选择
Refactor > Move - 在弹出的包选择框中输入目标包名（如
com.example.service.user），不要手动创建目录 - 确认后，VSCode会自动：
– 修改该文件顶部的package声明
– 更新所有其他文件中对该类的import语句
– 将文件物理移动到对应子目录（如src/main/java/com/example/service/user/）
– 重命名文件以匹配新类名（如果类名也变了）
为什么“移动类”比“重命名包”更可靠
VSCode没有单独的“重命名包”功能，所谓“改包名”本质是批量移动多个类到新包路径。但如果你逐个对每个类执行 Move，效率低且容易漏；而想靠全局搜索替换 package xxx，又会误伤字符串字面量或注释里的包路径。
Move Class 的优势在于它基于 AST 分析，只改真正属于该包声明的代码位置，且天然支持跨模块项目（Maven multi-module / Gradle composite build）：
- 它识别
module-info.java中的exports和opens指令，并提示是否同步更新 - 对 Spring Boot 的
@ComponentScan或@MapperScan注解不做修改（这是合理设计——扫描路径应由开发者显式控制） - 不会碰 XML 配置、properties 文件、JSON Schema 等非 Java 源码中的包引用（这点必须手动检查）
移动后编译报错？先盯住这三处
即使用了 Move Class，仍有小概率编译失败。高频问题就集中在以下三个地方，顺序排查最省时间：
-
mvn compile报package com.example.oldpackage does not exist：说明某处 import 还没刷新，重启 VSCode + 执行Java: Clean the Java language server workspace（命令面板里搜） - 运行时报
NoClassDefFoundError：检查pom.xml或build.gradle是否把旧包路径写死在resources过滤或插件配置里（比如maven-resources-plugin的includes） - Spring 启动失败，提示找不到 Bean：确认
@Configuration类或@Import中是否硬编码了旧类的全限定名（如new OldService()），这类反射式引用无法被重构捕获
多模块项目里跨 module 移动类，要额外做两件事
在 Maven 多模块结构中，把类从 common 模块移到 service 模块，光靠 Move Class 不够——它不会自动加依赖，也不会删掉旧模块的导出声明。
- 手动编辑
service/pom.xml，确保有<dependency></dependency>引用common（如果移动后仍需旧模块其他类） - 检查
common/pom.xml的<dependencies></dependencies>和<build></build>部分，移除已迁出类相关的测试或插件配置（例如该类曾被maven-surefire-plugin单独指定为测试入口）
最易被忽略的是模块间 API 边界：一旦类被移走，common 模块的 public API 表面收缩，但下游模块可能还通过反射或 ServiceLoader 加载它——这种隐式契约，没有任何重构工具能帮你发现。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
