工具类应为final且私有构造，确保无状态、纯函数化、职责单一、命名精准、接口清晰。需显式传参、防御校验、泛型安全、不可变操作，并按语义垂直拆分，杜绝commonutils等模糊命名。
把复杂算法封装成独立工具类，核心是剥离业务耦合、明确职责边界、保证可复用与可测试性。不是简单把代码塞进 static 方法，而是让算法本身成为“即插即用”的能力单元。
用 final 类 + 私有构造器锁定工具类契约
防止被继承、实例化或误用，这是工具类的底线约束：
- 类必须声明为 final，杜绝子类覆盖或扩展行为
- 构造方法必须是 private Utils() {}，哪怕所有方法都是 static，缺它就可能被反射创建实例
- 不提供任何 public 构造器，也不依赖 Spring 等框架自动注入——工具类天生无状态、无生命周期
算法方法要纯函数化，拒绝隐式依赖
所谓“纯”，是指相同输入永远返回相同输出，且不修改入参、不读写外部状态：
- 避免在方法里访问 static 字段、单例对象、配置中心、系统时区、当前时间 等隐式上下文
- 需要时区、精度、编码等参数，就显式作为方法参数传入，例如：
formatDate(Date date, String pattern, ZoneId zone) - 不要修改传入的集合或对象，如需转换，返回新对象（
Collections.unmodifiableList()或new ArrayList(src)）
按算法语义垂直拆分，不堆砌大而全的类
一个工具类只聚焦一类问题，命名直指用途，比如：
- CartesianProductUtils：专注笛卡尔积生成，支持泛型、空集合容错、递归/迭代双实现
- RSAEncryptionUtils：封装密钥生成、公钥加密、私钥解密、签名验签全流程，屏蔽 Cipher 初始化细节
-
BigDecimalCalcUtils：统一处理加减乘除、舍入模式、空值策略、精度校验，避免业务中裸写
setScale(2, HALF_UP)
别用 CommonUtils 或 Helper 这类模糊名称——它迟早变成没人敢动、不敢测的技术债温床。
暴露清晰接口，兼顾类型安全与调用简洁
静态方法不是越少参数越好，而是让调用者一眼看懂“要什么”和“能控制什么”：
- 用泛型方法替代原始类型返回，例如：
public static <t> List<t> combine(List<t> a, List<t> b)</t></t></t></t> - 对关键参数做防御性校验，抛出明确异常（
IllegalArgumentException而非NullPointerException） - 提供重载方法适配常见场景，如默认精度、默认字符集、默认超时，但底层共用同一主逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
