关键在于按需分层控制：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，但这是黑盒行为，应尽快迁移为命名模块并显式控制