jrebel 启动后没生效的主因是未正确配置项目级激活：需在 src/main/resources 下放置 jrebel.xml，确保 maven 编译版本与 jdk 一致，ide 中禁用“delegate to maven”，且避免与 spring-boot-devtools 冲突。
为什么 JRebel 启动后没生效？常见配置漏项
不是插件装上就自动热更，JRebel 需要显式激活项目级配置。IDE 里点“Enable JRebel”只是开关，真正起作用的是 jrebel.xml 或注解扫描规则。
- Spring Boot 项目必须在
src/main/resources/下放jrebel.xml，否则 Controller/Service 修改不触发重载 - 使用 Maven 构建时，
maven-compiler-plugin的source和target版本需与 JDK 一致，否则 class 字节码结构不匹配，JRebel拒绝加载 - IntelliJ 中启用
JRebel后，还要确认 Run Configuration → “Delegate IDE build/run actions to Maven” 未勾选，否则绕过JRebel编译流程
JRebel 和 spring-boot-devtools 能不能共存？
能共存，但会互相干扰——devtools 的 restart 机制会杀死 JVM 进程，而 JRebel 依赖 JVM 持续运行来做类替换。两者同时启用，大概率出现“改了代码没反应”或“重启两次”的现象。
- 优先用
JRebel：关掉spring.devtools.restart.enabled=true，删掉spring-boot-devtools依赖 - 若必须保留
devtools（比如某些第三方库依赖其资源监听），则禁用其自动重启：spring.devtools.restart.enabled=false，仅保留 LiveReload 功能 -
JRebel对 Spring AOP、CGLIB 代理类支持更好，devtools在涉及@Transactional或@Async的类上热更失败率更高
修改哪些代码能被 JRebel 立即生效？边界在哪？
JRebel 不是万能的，它只替换 JVM 中已加载类的字节码，不改变类结构或 JVM 运行时状态。以下修改可生效：
- 方法体内部逻辑（
return "new value";→return "updated";） - 字段值（
private String msg = "old";→"new"），但仅限非final、非static final - 新增/删除非
private方法（public/protected），前提是调用方未被 JIT 编译锁定
这些改不了：
立即学习“Java免费学习笔记（深入）”；
- 添加/删除字段（会触发类结构变更，需 full restart）
- 修改
enum常量值（JVM 把 enum 视为单例对象，值不可变） - 调整泛型签名（如
List<string></string>→List<integer></integer>），JVM 类型擦除后无法安全替换
本地开发用 JRebel，上线还用得着吗？
不用。JRebel 是纯开发期工具，所有 agent 行为都依赖启动参数 -javaagent:/path/to/jrebel.jar，生产环境禁止引入。
- 它的 agent 会持续 hook JVM 类加载器，增加 GC 压力和内存占用，压测时可能掩盖真实性能瓶颈
- 部分安全策略（如 Java SecurityManager 或容器级类加载隔离）会直接拒绝
JRebel的 instrument 操作 - 真正需要关注的是：开发阶段是否养成了“靠热更掩盖频繁重启暴露的问题”的习惯？比如没清理静态缓存、没释放线程池——这些在线上必然炸
热部署不是免检通行证，它只加速验证，不替代对生命周期和状态管理的理解。
