工具类构造函数必须私有并抛出异常，以防止被实例化；所有方法须为public static，类应声明为final，杜绝继承与状态维护，确保纯函数式语义。
为什么工具类的构造函数必须私有
因为 Java 默认提供无参公有构造函数，只要没显式定义，编译器就自动加一个；一旦类里有公有构造函数，哪怕只写了一次 new Utils()，别人就能复制粘贴照用——工具类就“破防”了。私有化不是为了防自己，是防调用方误用。
常见错误现象：java.lang.InstantiationException 不会报（那是反射失败），真正问题是 IDE 不报错、编译通过、运行时也正常，但语义上完全违背工具类定位：它不该有状态，也不该被当成对象来 new。
- 必须把构造函数声明为
private Utils()，且不能留空——要加throw new UnsupportedOperationException("Utility class cannot be instantiated") - 如果类里已有其他构造函数（比如带参数的），默认无参构造不会自动生成，但你仍得手动补上私有无参构造，否则别人可能通过其他构造实例化
- 静态内部类不需要私有构造，但外层工具类必须有，否则外部仍可 new
static 方法 + 私有构造是唯一可靠组合
只加 private 构造函数还不够。如果工具类里混了非 static 字段或方法，JVM 仍允许通过反射绕过私有检查（虽然不推荐，但确实可行）。真正锁死语义的方式，是让所有能力都通过 static 暴露，同时切断实例化路径。
使用场景：像 StringUtils、CollectionUtils 这类纯函数式工具，没有字段、不维护状态、不依赖 this。
立即学习“Java免费学习笔记（深入）”；
- 所有方法必须声明为
public static，避免隐式依赖实例上下文 - 禁止出现
this、super、非 static 内部类引用 - 如果真需要初始化逻辑（比如预热缓存），放在 static 块里，而不是构造函数中
- IDE 可能提示“Method can be static”，这类警告别忽略——它其实在提醒你：这个方法本就不该绑定实例
继承工具类？直接报错才最安全
有人会想“我继承一下，加点新方法”，结果发现子类能 new，父类的私有构造根本挡不住。这不是设计缺陷，是故意不支持——工具类不是模板，不是基类，它就是一包函数集合。
错误现象：子类写了 public SubUtils() { super(); }，编译失败，报 Illegal constructor access；但如果父类构造只是 private 而没 throw 异常，子类甚至可能通过反射调用成功，造成逻辑混乱。
- 在私有构造里必须抛异常，不只是
private Utils() {} - 加上
final修饰类（public final class StringUtils），从语法层面禁止继承 - 如果真要扩展功能，用组合：新建一个工具类，内部调用原工具类的 static 方法
Lombok 的 @UtilityClass 看似省事，但藏坑
它自动生成私有构造 + final 类 + 所有方法 static，看起来完美。但问题在于：它不校验你是否真没写实例字段或 this 引用。一旦误加了 private String cache，Lombok 仍会生成 static 方法，而字段变成类变量，多线程下可能出问题。
性能影响不大，但语义污染严重——你以为写的是无状态工具，实际悄悄持有了可变状态。
- 启用
@UtilityClass后，类里不能有任何非 static 字段，包括private static final以外的常量 - 不要依赖它来“修复”已有类；旧类加了这个注解，可能让原本靠构造函数初始化的逻辑失效
- 团队协作时，不如手写明确的
private Utils()+throw+final，代码意图更直白，review 时一眼看清
最容易被忽略的一点：私有构造函数本身不会阻止反射实例化，但加上运行时异常和 final 类修饰后，任何试图 new 或继承的行为都会在编译期或运行初期暴露，而不是等到线上跑几天才发现某处偷偷 new 了工具类还改了它的状态。
