模块系统不解决泛型类型擦除，module-info.java 仅控制可见性与依赖，不影响运行时泛型行为；跨模块泛型元数据丢失主因是缺少 opens 声明导致反射受限，需用 opens 替代或补充 exports 以保障 getgenerictype() 等正常工作。
模块系统本身不解决泛型类型擦除问题——module-info.java 的作用是控制类的可见性与依赖关系，而非影响泛型在运行时的行为。类型擦除是 Java 编译器层面的机制，发生在编译期，与模块化无关。但实战中，跨模块调用时泛型信息“看似丢失”常源于模块封装导致的反射限制、类型访问受阻或桥接方法不可见等问题。真正要解决的，不是“阻止擦除”，而是确保泛型元数据可被安全、正确地读取和使用。
明确 module-info.java 的边界：它不干预泛型擦除
Java 泛型在字节码中被擦除（如 List
- 包是否对其他模块可见（exports）
- 运行时反射能否访问包内成员（opens）
- 服务加载机制能否发现实现类（uses / provides）
所以，若你在模块 B 中通过反射获取模块 A 中某个泛型字段的 Type（如 ParameterizedType），却得到 Class 而非完整泛型签名，问题往往不是“擦除发生了”，而是模块 A 没有 opens 对应包——导致反射被模块系统拦截，连 getGenericType() 都返回 null 或退化为 getClass()。
跨模块泛型元数据可读的关键：用 opens 替代 exports
当需要跨模块保留泛型结构（例如序列化框架、通用 DAO、注解处理器），仅 exports 不够。必须显式 opens 包，尤其对含泛型声明的类、字段、方法所在包：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- exports com.example.api; → 允许其他模块访问 public 类和方法，但反射受限
- opens com.example.model; → 允许其他模块在运行时通过反射读取该包下类的泛型字段/方法签名（包括 getGenericXxx() 返回完整 Type）
- 若需深度反射（如访问私有泛型字段），还可加 opens com.example.model to com.example.serializer;
示例：模块 A 定义 class Response
opens com.example.model; — 否则 Jackson 在模块 B 中调用 data.getClass().getDeclaredField("data").getGenericType() 会失败或返回 Object.class。
配合模块化设计泛型契约：避免运行时类型盲区
类型擦除不可逆，但可通过模块接口设计减少不确定性：
- 在 API 模块中定义泛型接口（如 Repository
），由实现模块提供具体类型（UserRepository extends Repository ），调用方依赖 API 模块，天然知晓泛型参数 - 用 requires static 声明编译期依赖（如 Lombok、MapStruct 注解处理器），确保泛型相关注解处理在编译阶段完成，不依赖运行时反射
- 避免在模块边界暴露“裸”泛型类型（如 List），改用具名容器类（UserList extends ArrayList
），并在模块中 exports 该类 —— 此时调用方看到的是具体类型，无需推断
调试泛型可见性问题的实操步骤
当跨模块泛型信息“消失”时，按此顺序排查：
- 检查目标类所在包是否被 opens（不只是 exports）
- 确认反射调用方模块是否在 opens 子句中被显式授权（如 opens pkg to caller.module;）
- 用 javap -v 查看目标类字节码，验证泛型签名是否存在于 Signature 属性中（存在即编译器已保留，问题在运行时访问）
- 在调用处加日志：field.getGenericType().getTypeName()，若为 null 或 Object，基本确定是模块封装拦截了反射
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
