Java热加载依赖JVM的HotSwap能力及IDE调用JDWP和Instrumentation.redefineClasses实现，但仅支持方法体修改；字段、方法签名或类结构变更需重启或借助Spring Boot DevTools。
Java热加载在IDE里到底靠谁干活
IDE本身不直接执行热加载，真正起作用的是底层JVM的HotSwap能力，加上IDE调用的调试协议（JDWP）和类重定义接口（Instrumentation.redefineClasses）。但HotSwap有硬限制：只能改方法体，不能增删字段、方法签名、类结构。所以你改了private String name为private int age，IDE点“Reload”大概率没反应——不是配置错了，是JVM根本不让。
- 改方法内部逻辑（比如
if变switch、加一行log.info()）→ 通常能立刻生效 - 加一个新
private void helper()→ 不生效，需手动触发Build → Build Project再重载 - 修改
@SpringBootApplication类上的注解 → 必须重启，HotSwap完全不处理类元数据
IntelliJ IDEA里开启热加载的关键开关
IntelliJ默认开了基础热加载，但多数人卡在两个隐藏设置上：
-
Settings → Build, Execution, Deployment → Compiler → Build project automatically必须勾选 -
Settings → Advanced Settings → Allow auto-make to start even if developed application is currently running也必须勾选（旧版叫Compile independent modules in parallel下面的开关）
不打开第二个，IDE会在你运行Spring Boot时自动禁用自动编译，改完代码根本不会触发class文件更新，自然没法热加载。
- 启动应用时用
Debug模式，不是Run模式（Run不启用JDWP，无法重定义类） - 确保项目是
Java 8u40+或Java 11+，老JDK对HotSwap支持极弱，甚至改方法体都失败 - 如果用Maven多模块，检查
Build → Build Modules是否只编译当前变更模块，避免全量构建拖慢反馈
Spring Boot DevTools为什么比原生HotSwap好用
DevTools不是绕过JVM限制，而是换了一套机制：它监听class文件变化，触发ClassLoader卸载+重新加载整个类（类似OSGi），所以能支持字段增删、配置刷新、模板热更。但它需要你主动引入依赖：
立即学习“Java免费学习笔记（深入）”；
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> </dependency>
- 必须把
spring-boot-devtools放在runtimescope，否则打包进jar后可能引发生产环境问题 - 启动时控制台出现
LiveReload server is running on port 35729说明生效；没这行，多半是IDE没识别到devtools（检查File → Project Structure → Modules里是否包含该依赖） - 它会自动禁用Thymeleaf缓存、静态资源缓存，但
@ConfigurationProperties类的属性更新仍需手动触发RefreshScope或用/actuator/refresh端点
常见“热加载失效”的真实原因和排查顺序
看到改了代码没反应，别急着重装插件，按这个顺序查：
- 检查
Build → Build Project有没有报错（哪怕只是警告，比如Lombok未启用注解处理器，也会导致class没生成） - 看
target/classes（Maven）或out/production（IntelliJ）下对应class文件的修改时间是否更新，没更新就是编译根本没跑 - 控制台是否有
reloading class X.Y.Z或Restarting due to changes...日志，没有就说明热加载链路断在IDE或devtools层 - 用
jps -l确认进程是org.springframework.boot.devtools.restart.RestartLauncher开头，而不是裸的java.Main——后者说明devtools压根没启动
热加载不是魔法，它是一连串“编译→写class→通知JVM→JVM接受→替换类”的协作。任一环节卡住，表现都是“改了没用”。最常被忽略的是：你以为改的是A类，实际运行的是B模块里的旧A类——尤其在多模块、依赖传递、IDE缓存classpath的情况下。
