工具类必须加私有构造器并抛出AssertionError，以防止编译器生成默认公有构造器导致误实例化；同时应声明为final类，避免继承；abstract方式无效且误导。
为什么工具类必须加私有构造器？
因为不加，Java 编译器会偷偷给你补一个公有的无参构造器，别人就能 new StringUtils()，而这个实例完全没用，还可能误导人以为它能存状态、可复用。
这不是“防坏人”，是防自己和同事手滑。比如你写了个 DateUtils，只放了 format() 和 parse() 两个静态方法，结果某天测试代码里冒出一行 new DateUtils().format(...) —— 编译通过，运行也“不报错”，但对象白建、内存白占、语义全乱。
怎么写才真正阻止实例化？
两步：声明 private 构造器 + 主动抛异常。光私有还不够，万一哪天你在类内部误调用了呢？加 throw new AssertionError() 是兜底保险。
private StringUtils() { throw new AssertionError("No instance for utility class"); }- 必须显式写出构造器，否则编译器仍会生成默认公有构造器
- 类名建议加
final（如public final class StringUtils），进一步封死继承可能
常见错误：用 abstract 代替 private 构造器？
不行。把工具类声明为 abstract class StringUtils 看似“不能 new”，但子类可以继承并实例化，比如 class MyUtils extends StringUtils {} 然后 new MyUtils() —— 还是绕开了限制，而且严重误导：别人会以为这货是模板基类。
更糟的是，抽象类会让人下意识去重写方法、加字段，违背工具类“纯静态”的本意。
反射真能绕过私有构造器吗？需要防吗？
能，但没必要专门防御。用 Constructor.setAccessible(true) 确实可以强行调用私有构造器，但这属于“主动攻击”，不是误用。工具类被反射实例化后既不保存状态，也不改变行为，顶多浪费一个对象——跟直接 new 一个 Object() 没本质区别。
所以，AssertionError 不是为了防反射，而是防内部误调、防编译期漏检、防新人看不懂意图。真有反射需求的场景，早就不该用工具类了。
真正容易被忽略的点是：私有构造器会让整个类无法被继承，这不是 bug，是 feature。如果你发现某个“工具类”后面悄悄被继承了，那说明设计本身就有问题——要么它不该是工具类，要么它早该拆成接口+实现。
