Collections 不做反射拦截是因为反射是 JVM 层级能力，无法被工具类自身拦截；其私有构造函数仅用于表达设计意图，而非技术封锁，真正防护应从设计源头规避风险。
Collections 工具类本身已通过私有构造函数 + throw new AssertionError 的方式禁止实例化，它不提供反射拦截机制——Java 反射天然可以绕过访问控制，所谓“拦截”并非 Collections 自身行为，而是开发者需在设计层面主动防御。
为什么 Collections 不做反射拦截
Java 反射的 setAccessible(true) 是 JVM 层级的运行时能力，任何私有成员（包括构造函数）都可被强行访问。Collections 作为 JDK 标准库工具类，其设计目标是明确表达不可实例化的意图，而非技术上杜绝反射创建。JDK 并未、也不应为反射留后门做“拦截”，否则会破坏反射机制本身的可信基础。
私有构造函数的标准写法（含防御性提示）
这是 Collections 实际采用的模式，也是推荐实践：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 声明
private Collections()构造函数 - 函数体中抛出
AssertionError或UnsupportedOperationException，带清晰提示信息 - 类声明为
final，防止子类绕过构造限制 - 不依赖反射检测或运行时校验——既无效，也增加开销
若真需阻止反射实例化，只能靠运行时检查（不推荐）
严格来说，没有 100% 可靠的拦截手段，但可在构造函数内做轻量级堆栈检查，识别典型反射调用特征（如 java.lang.reflect 相关类名），并提前拒绝：
立即学习“Java免费学习笔记（深入）”；
- 获取当前线程栈：
Thread.currentThread().getStackTrace() - 遍历栈帧，检查是否含
"sun.reflect"、"java.lang.reflect"或常见反射工具类路径 - 发现可疑调用时，抛出异常（例如
new SecurityException("Reflection instantiation denied")） - 注意：该方式可被混淆、字节码修改或自定义 ClassLoader 规避，仅作警示用途
真正有效的防护思路
与其试图“拦截反射”，不如从设计源头消除风险：
- 工具类只暴露静态方法，不持有状态；即使被反射实例化，对象也无实际用途
- 代码审查时关注是否误用
new Collections()，IDE 和静态分析工具（如 SpotBugs）能直接报错 - 团队规范明确禁止对工具类使用反射，将其视为违反契约的行为
- 若涉及敏感逻辑（如权限校验），不应放在工具类中，而应封装进受控的 Service 或 Manager 类
