迁移时包变量碎片问题本质是模块化后强封装导致旧项目中散落的public类、字段或方法不可见，引发noclassdeffounderror等错误；解决核心是用module-info.java显式定义exports/opens边界，并结合jdeps扫描、ide用法分析、分层导出及自动模块适配策略进行重构与验证。
迁移时包变量碎片问题，本质是旧项目中大量 public 类、字段或方法散落在未导出的包里，模块化后因强封装机制直接不可见，导致编译失败或运行时报 NoClassDefFoundError、IllegalAccessError。解决核心不是“绕过封装”，而是用 module-info.java 显式定义可见边界，并配合合理重构。
识别并归类“碎片化包变量”
先定位哪些包里的 public 成员实际被外部调用：
- 用
jdeps --list-deps --multi-release 17 your-app.jar扫描依赖图，重点关注“unresolved”或“not found”提示的类引用 - 在 IDE 中右键点击疑似被跨包使用的类 → “Find Usages”，观察调用方是否来自其他模块（或传统 classpath）
- 特别检查工具类（如
StringUtils）、配置类（如AppConfig）、DTO/VO 包——这些最常成为碎片源头
按用途分层处理 exports 和 opens
不能简单把整个包 exports 出去，要区分访问场景：
-
API 层（稳定对外）：明确提取接口和 DTO 到独立包（如
com.example.api），在module-info.java中exports com.example.api; -
实现层（仅限框架反射）：如 Spring Boot 的
@Configuration类、Jackson 反序列化的实体，用opens com.example.model to java.base, com.fasterxml.jackson.databind; -
内部工具类（不对外）：若确认只被本模块内使用，保留包不导出；若被测试代码调用，可加
opens给org.junit.platform.commons，或改用test模块分离
兼容非模块化第三方库的过渡策略
当你的模块依赖了像 hutool-core 这类无 module-info.class 的 JAR 时：
- 它会自动转为“自动模块”，模块名默认取 JAR 名（如
hutool.core），你可在requires hutool.core;引用 - 但自动模块会隐式导出所有包，破坏封装性；建议用
jdeps --generate-module-info src/ *.jar生成临时module-info.java，再手动删减，只保留真正需要的exports - 若该库被反射深度调用（如 Hibernate 映射），需在你自己模块中补
opens声明，例如：opens com.example.entity to org.hibernate.orm.core;
构建与运行时验证关键点
光写对 module-info.java 不够，必须验证是否真生效：
- 编译阶段加
--module-source-path和--module-path，确保 JDK 按模块路径解析 - 运行时启动加
--illegal-access=deny，强制暴露非法反射访问，比默认警告更早发现问题 - 打包后用
jlink构建最小镜像，如果失败，说明仍有隐式依赖未声明 —— 此时回看jdeps -s输出的“missing dependencies”部分
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
