关键在于按需分层控制：exports决定类是否可见，opens限定反射访问权限；典型做法是exports API包、opens内部实现包并用to指定接收方，禁用--add-opens生产部署。
要让其他模块既能正常使用你的类，又不让框架因反射受限而报错，关键不是“全开”或“全关”，而是按需分层控制。exports管的是“能不能看见”，opens管的是“能不能深挖”，两者配合才能既守住封装底线，又不卡住开发手脚。
明确分工：exports负责常规调用，opens专供反射
一个包如果只被exports，其他模块能import、能new、能调用public方法，但无法通过反射读取private字段或调用package-private构造器。反之，如果只opens不exports，编译期就报错——因为连类名都找不到。所以典型做法是：
- 把API接口和DTO类所在的包用exports声明，比如
exports com.example.api; - 把需要被Jackson、Hibernate等框架序列化或注入的内部实现包，额外用opens声明，比如
opens com.example.model to com.fasterxml.jackson.databind; - 绝不单独opens一个未exports的包——那等于开了门却没装锁，反而制造混乱
定向开放：用to限制反射权限范围
全局opens（如opens com.example.internal;）会把整个包对所有模块开放反射，风险太高。更稳妥的是指定接收方：
-
opens com.example.db to org.hibernate;：仅允许Hibernate反射访问数据库实体 -
opens com.example.config to java.xml.bind;：只放行JAXB对配置类的反射操作 - 若多个框架都需要，可写成
opens com.example.dto to com.fasterxml.jackson.databind, org.springframework.core;
这样即使某框架存在漏洞，攻击面也被严格限定在它被授权访问的包内。
运行时兜底与生产收敛
开发调试阶段可用--add-opens临时补救，比如：--add-opens java.base/java.lang=ALL-UNNAMED。但这只是权宜之计，不能进生产部署：
- 上线前必须把所有
--add-opens迁移到module-info.java中对应opens ... to ...语句 - 禁用
--illegal-access=permit或设为deny，强制暴露问题而非掩盖 - 配合SecurityManager策略，拦截非法
setAccessible(true)调用，形成双重防护
避免常见陷阱
实际项目中最容易踩的坑不是不会用，而是误判访问层级：
- 不要以为public类就天然可被反射——模块未opens，
getDeclaredMethod仍抛InaccessibleObjectException - 不要在同一个module-info里重复导出子包，如已
exports com.example;，再exports com.example.api;无效且冗余 - 自动模块（无module-info的JAR）默认全部opens，但这是黑盒行为，应尽快迁移为命名模块并显式控制
