Collections 不做反射拦截是因为反射是 JVM 层级能力，无法被工具类自身拦截；其私有构造函数仅用于表达设计意图，而非技术封锁，真正防护应从设计源头规避风险。
Collections 工具类本身已通过私有构造函数 + throw new AssertionError 的方式禁止实例化，它不提供反射拦截机制——Java 反射天然可以绕过访问控制，所谓“拦截”并非 Collections 自身行为，而是开发者需在设计层面主动防御。
为什么 Collections 不做反射拦截
Java 反射的 setAccessible(true) 是 JVM 层级的运行时能力，任何私有成员（包括构造函数）都可被强行访问。Collections 作为 JDK 标准库工具类，其设计目标是明确表达不可实例化的意图，而非技术上杜绝反射创建。JDK 并未、也不应为反射留后门做“拦截”，否则会破坏反射机制本身的可信基础。
私有构造函数的标准写法（含防御性提示）
这是 Collections 实际采用的模式，也是推荐实践：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 声明
private Collections()构造函数 - 函数体中抛出
AssertionError或UnsupportedOperationException，带清晰提示信息 - 类声明为
final，防止子类绕过构造限制 - 不依赖反射检测或运行时校验——既无效，也增加开销
若真需阻止反射实例化，只能靠运行时检查（不推荐）
严格来说，没有 100% 可靠的拦截手段，但可在构造函数内做轻量级堆栈检查，识别典型反射调用特征（如 java.lang.reflect 相关类名），并提前拒绝：
- 获取当前线程栈：
Thread.currentThread().getStackTrace() - 遍历栈帧，检查是否含
"sun.reflect"、"java.lang.reflect"或常见反射工具类路径 - 发现可疑调用时，抛出异常（例如
new SecurityException("Reflection instantiation denied")） - 注意：该方式可被混淆、字节码修改或自定义 ClassLoader 规避，仅作警示用途
真正有效的防护思路
与其试图“拦截反射”，不如从设计源头消除风险：
- 工具类只暴露静态方法，不持有状态；即使被反射实例化，对象也无实际用途
- 代码审查时关注是否误用
new Collections()，IDE 和静态分析工具（如 SpotBugs）能直接报错 - 团队规范明确禁止对工具类使用反射，将其视为违反契约的行为
- 若涉及敏感逻辑（如权限校验），不应放在工具类中，而应封装进受控的 Service 或 Manager 类
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
