工具类必须声明为final且含private构造方法并抛出异常，以彻底禁止实例化；仅private构造器不够，需防反射、继承和反序列化，同时向团队传递“纯静态工具”设计意图。
工具类构造方法用 private 修饰，核心目的是从编译期就切断外部 new 实例的可能——因为工具类只提供静态方法，实例化毫无意义，还可能引发内存浪费、语义混淆和维护风险。
必须写 private 构造器，且不能留空
Java 不会自动加 private 构造器。哪怕类里全是 static 方法，只要没显式声明，编译器就会默认生成一个 public 无参构造器。所以必须手动补上：
- 声明为
private Utils() { ... } - 构造体里要抛异常，比如
throw new UnsupportedOperationException("Cannot instantiate utility class"); - 只写空的
private Utils() {}不够——反射仍可成功创建 null 字段对象，起不到实质防护
类本身要加 final 修饰
光私有构造器还不够。如果类不是 final，别人可以继承它，子类在内部合法调用 super()，间接绕过限制：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 必须写
public final class StringUtils { ... } - CheckStyle、PMD 等代码检查工具会明确警告：缺少 final 就算不合规
- final 还能防止子类篡改静态行为，增强线程安全假设
防住反射和反序列化这类“后门”
private 构造器挡不住反射（constructor.setAccessible(true)）或反序列化（ObjectInputStream.readObject()）。需要运行时兜底：
立即学习“Java免费学习笔记（深入）”；
- 构造器内加判断：
if (this != null) throw new UnsupportedOperationException();（虽然 this 在构造中恒为 null，但这是惯用写法；更稳妥的是直接抛异常） - 不实现
Serializable接口——工具类本就不该被序列化 - 若真要支持序列化，需定义
private Object readResolve() { return INSTANCE; }，但一般没必要
别忘了 IDE 和团队协作信号
IntelliJ 等 IDE 会在没加 private 构造器时提示：“Utility class may be refactored to enum or final class with private constructor”。这不是警告，是设计提醒：
- 加了 private 构造器 + final，等于向所有协作者宣告：这个类只用来调静态方法
- 单元测试也不该 new 它——直接调
Utils.doSomething()即可 - Mockito 无法 mock 这类类，正说明它不该有实例行为
