核心思路是利用JPMS包级封装与类访问修饰符双重防护：1. module-info中仅exports必要API包，internal/model包默认封装；2. 内部类用包私有或private修饰，public类构造器设为private/package-private；3. 避免自动模块破坏边界，用jdeps检测并--limit-modules限制；4. 反射场景下构造器内校验调用栈。
核心思路是：利用模块系统（JPMS）的包级封装 + 显式导出控制，配合类级别的访问修饰符（如 private、package-private），从 JVM 层面阻断外部模块对内部类及其构造器的可见性与可访问性。
1. 用 module-info.java 严格限制包导出
即使某个类声明为 public，只要它所在的包未在 module-info.java 中被 exports，外部模块就无法访问该类——包括其构造器。这是 JPMS 最根本的防护层。
- 只导出真正需要对外暴露的 API 包，例如
exports com.example.api; - 把含内部类、工具类、DTO 或敏感构造逻辑的包设为不导出（即默认封装），例如
com.example.internal或com.example.model - 若需反射支持（如 JSON 序列化），仅对必要包使用
opens，而非open module；opens不影响构造器的编译期可见性，但允许运行时反射访问
2. 内部类本身采用最小化访问权限
模块封装是第一道门，类内访问控制是第二道锁。对不希望被外部实例化的内部类，应主动收窄其可见性：
- 非 public 类（即包私有，默认无修饰符）天然无法被其他模块访问，哪怕该包被 exports —— 因为
exports只开放public类型 - 嵌套类优先用
static修饰，避免隐式持有外部类引用；若必须非静态，且仅限本类使用，可声明为private static class Helper - 即使类是
public，也可将构造器设为private或package-private，配合模块封装，双重拦截
3. 避免自动模块破坏封装边界
当项目引入未声明 module-info.java 的第三方 JAR（即自动模块）时，JVM 会将其所有 public 类全局可见，可能绕过你精心设计的模块封装。这会间接导致内部类变量被误用或反射实例化。
- 检查依赖树，用
jdeps --module-path lib/ --summary app.jar识别自动模块 - 对关键模块，通过
--limit-modules启动参数显式限定可加载模块范围 - 若必须使用自动模块，确保其不包含你内部类的同名类，防止类加载冲突和意外覆盖
4. 反射场景下补充运行时校验（可选增强）
模块封装能防住绝大多数非法实例化，但反射仍可能穿透（尤其在 opens 后）。可在构造器中加入轻量级堆栈检查：
- 在私有/包私有构造器首行调用
Objects.requireNonNull(Reflection.getCallerClass())（Java 8+）或检查new Throwable().getStackTrace() - 若发现调用者类不属于预期包或模块（如非
com.example.internal或非本模块），直接抛IllegalAccessError - 注意：此方式有轻微性能开销，适合安全敏感场景，非必需路径可省略
