模块化强封装不能直接防止单例被反射破坏，但通过将单例类、构造器、实例字段置于未导出未开放的私有模块包内，配合JVM反射限制与权限控制，可大幅提高攻击门槛。
模块化强封装本身不能直接防止单例被反射破坏，但它能大幅提高攻击门槛——关键在于把单例类、构造器、实例字段全部收进未导出且未开放的包内，并配合运行时权限控制。
将单例彻底封入私有模块包
仅靠 private 构造器和 static instance 字段远远不够。必须让单例类所在的包既不 exports 也不 opens：
- 在 module-info.java 中完全省略该包的 exports 和 opens 声明
- 确保单例类（如
SecretConfigManager）和它的包（如com.example.internal）不在任何模块依赖链的可见路径中 - 对外只暴露不可变接口（如
ConfigService），且该接口定义在另一个 exports 的公共包里
用模块层+反射权限双控阻断 setAccessible
即使攻击者拿到类名，若模块未开放、JVM 禁止非法反射，setAccessible(true) 会直接抛 InaccessibleObjectException：
- 启动时添加 JVM 参数：
--add-opens java.base/java.lang=ALL-UNNAMED（仅开必需项，不开放你的模块） - 生产环境禁用宽松反射：
--illegal-access=deny（JDK 16+ 默认行为） - 搭配 SecurityManager（如启用）授予
ReflectPermission("suppressAccessChecks")给可信模块，拒绝其他代码
单例实现优先选枚举 + 模块封装组合
枚举天生防反射创建（无 public 无参构造）、防反序列化重建，再放进封闭模块，形成双重保险：
- 定义
public enum ConfigHolder { INSTANCE; }，放在com.example.internal包下 -
module-info.java 不声明
exports com.example.internal，也不opens com.example.internal - 对外提供静态工厂方法：
public static ConfigService getInstance()，返回INSTANCE转换后的接口视图 - 即使通过反射获取到枚举类，
c.getDeclaredConstructor()会失败（JVM 特殊处理枚举构造器）
运行时主动防御：构造器内检活+模块上下文校验
在单例构造器中增加轻量级防护逻辑，结合模块系统 API 判定调用来源是否合法：
- 调用
ModuleLayer.boot().modules()或getClass().getModule()获取当前模块 - 检查调用栈中最上层非 JDK 类所属模块是否在预设白名单内（如仅允许
com.example.api模块触发） - 若检测到非法反射调用（如
java.lang.reflect.Constructor.newInstance在栈中），立即抛SecurityException
