JDK 9+生产环境崩溃主因是JVM拦截跨模块反射，需通过InaccessibleObjectException堆栈定位被拦模块、包及触发行，再依部署形态（unnamed命名模块/Spring Boot）选JVM参数或module-info修复，并优先用package-private、@JsonCreator等替代反射。
这类崩溃在 JDK 9+（尤其是 17+）生产环境中非常典型，不是代码写错了，而是 JVM 主动拦截了跨模块反射行为。关键要从异常本身出发，快速定位被拦的模块和包，再精准放开权限或替换方案。
看懂 InaccessibleObjectException 堆栈
这是最直接的线索。重点提取三部分信息：
- “Unable to make method xxx privateMethod() accessible” → 确认是方法（不是字段），且调用方用了
getDeclaredMethod+setAccessible(true) - “module java.base does not 'opens java.time' to unnamed module” → 明确源模块（java.base）、目标包（java.time）、你的模块类型（unnamed）
- Caused by 行末尾的类名和行号 → 定位到具体哪一行触发了反射，是框架代码还是你自己的适配层
区分运行环境，选对修复方式
不能统一加 --add-opens ...=ALL-UNNAMED 就完事，得看实际部署形态：
- 传统 jar 包启动（classpath 模式）→ 应用处于 unnamed module，必须用 JVM 参数：如
--add-opens java.base/java.time=ALL-UNNAMED - 已声明
module-info.java的命名模块 → 在模块描述文件中加opens java.time to com.example.app;，只开放给指定模块 - Spring Boot 3 Fat Jar 启动 → Spring 默认仍走 unnamed module，参数需写在 Maven 插件的
jvmArguments或启动脚本里，application.properties无效
优先考虑替代方案，而非硬开权限
反射访问私有方法本质是破坏封装，JDK 升级后越来越不可靠。真要解耦或测试，更稳的做法是：
- 把私有方法改为 package-private（默认访问级别），测试类放同一包下，零反射、零参数
- 用
@VisibleForTesting标记，既是文档提示，也方便后续重构时暴露必要接口 - 若为 Jackson 反序列化需求 → 改用
@JsonCreator+ 全参构造器，或@JsonProperty配合 public setter - 若为 Mockito 测试私有逻辑 → 升级到 Mockito 5+，改用
mockConstruction()或将逻辑抽离为独立 service 接口
验证是否真需要反射
很多报错看似是“访问不了私有方法”，实则是设计缺陷。比如：
- 框架内部硬编码了
field.setAccessible(true)，但没适配新 JDK —— 查它最新版是否已修复（如 MyBatis-Plus ≥3.5.3、Lombok ≥1.18.30） - 自己写的工具类反复调用
setAccessible(true)→ 直接删掉，改用标准 API 或委托模式 - 日志或监控代码试图读取私有状态字段 → 改为提供 public getter，或通过 JMX/Metrics 暴露指标
