工具类必须同时用final和private构造器：final阻止继承，private构造器阻止实例化（含反射），二者缺一不可，否则破坏纯静态语义。
为什么工具类要同时用 final 和私有构造器
因为只加 final 不能阻止反射创建实例，只私有构造器又拦不住继承（子类仍可调用 super()，除非构造器是 private）。二者缺一不可，否则工具类可能被意外实例化或继承，破坏“纯静态方法容器”的语义。
常见错误现象：new StringUtils() 编译报错但反射绕过（Class.forName("...").getDeclaredConstructor().setAccessible(true).newInstance()），或子类继承后误覆写静态方法导致调用歧义。
-
final阻止编译期继承，也向 IDE 和协作者明确表达“不许扩展” - 私有构造器（
private Utils() {}）让实例化在编译期和运行期都失效（反射需显式破权，且应被安全策略拦截） - 不写任何构造器时，Java 默认提供 public 无参构造器——这是最容易踩的坑
如何正确声明一个不可继承的工具类
必须显式声明 private 构造器，并把类加上 final 修饰。顺序无关，但建议先写 final 再写构造器，避免漏掉。
final class DateUtils {
private DateUtils() {} // 必须存在，且必须是 private
public static String format(long ts) { ... }
public static long parse(String s) { ... }
}
- 构造器不能是
protected或包私有——它们仍允许同包内继承或实例化 - 构造器体内可以留空，也可以抛
UnsupportedOperationException，后者对反射调用更友好（失败更快、意图更明确） - 如果类里已有其他构造器（比如测试用的 package-private 构造器），必须确保它们全被删掉或改为
private
IDE 和 Lombok 会帮你掩盖什么风险
IntelliJ 默认提示“Missing constructor”，但如果你点了“Add default constructor”，它很可能加的是 package-private 的，不是 private；Lombok 的 @UtilityClass 虽然自动生成 private 构造器和 final，但它依赖注解处理器，且在某些构建环境（如旧版 Gradle + annotationProcessor 路径未配）下可能失效。
立即学习“Java免费学习笔记（深入）”；
- 检查生成字节码：用
javap -p DateUtils确认构造器是private DateUtils()，而非DateUtils() - Lombok 的
@UtilityClass会强制final，但如果你手动加了extends或implements，编译会直接失败——这是好事，说明约束生效了 - 不要依赖 IDE 自动生成的“constructor from superclass”选项，它完全不适用于工具类场景
为什么静态内部类不用加 final 也能安全
静态内部工具类（如 Outer.Utils）本身无法被外部继承，因为其完整类名含外层类名，而外层类非 public 时，该内部类默认不可见；即使可见，JVM 规范也不允许继承静态内部类（javac 直接拒绝）。
- 但为统一风格和可读性，仍建议显式加
final和private构造器 - 非静态内部类绝不能当工具类——它隐式持外层实例引用，违背无状态原则
- 模块化（JPMS）下，若工具类在
module-info.java中未导出，final更重要：防止跨模块继承尝试触发链接错误
private 构造器——尤其从普通类改工具类时，人容易只加 final 就以为完事。 
