静态工具类适合放通用转换函数，因其转换逻辑不依赖对象状态、无副作用、无上下文依赖，避免实例化开销；需声明为final、含私有构造函数、方法全为public static；接口设计应覆盖严格/宽松/函数式三档，注重边界处理、时区明确、格式显式、locale可控。
为什么静态工具类适合放通用转换函数
因为转换逻辑通常不依赖对象状态，比如 String 转 Integer、时间戳转 LocalDateTime，这类操作天然无副作用、无上下文依赖。用实例化类承载反而增加调用成本和理解负担——你不会为了调一次 parseInt 就 new 一个 Converter。
Java 中静态工具类的典型结构与命名规范
工具类名以 Utils 或 Converters 结尾（如 DateConverters），必须声明为 final，构造函数私有，所有方法用 public static 修饰。否则 IDE 会警告“Utility class may contain only static members”，且可能被意外继承或实例化。
常见错误现象：java.lang.InstantiationError 出现在反射调用时，往往是因为工具类没加私有构造函数；或者单元测试里误写 new StringUtils() 导致编译失败。
- 类必须声明为
final - 必须包含私有空构造函数：
private DateConverters() {} - 方法参数尽量使用不可变类型（
String、long、LocalDateTime），避免传入ArrayList后被外部修改影响结果
如何设计安全、可复用的转换方法签名
关键不是“能转”，而是“转得清楚、错得明白”。比如字符串转数字，不能只提供 toLong(String)，还要区分是否允许 null、是否抛异常、是否有默认值。
推荐三档接口：
-
parseLong(String s)：严格模式，s == null或格式错误直接抛NumberFormatException -
parseLong(String s, long defaultValue)：宽松模式，异常时返回默认值（注意：默认值不能是-1这类业务敏感值） -
tryParseLong(String s)：函数式风格，返回Optional<long></long>，调用方自行决定怎么处理空值
性能影响：用 Optional 会轻微增加对象分配，高吞吐场景慎用；但比 try-catch 做流程控制快得多——异常创建开销远大于对象创建。
容易被忽略的边界情况与兼容性陷阱
很多转换函数在 JDK 升级后行为突变。比如 LocalDateTime.parse("2023-01-01") 在 JDK 8 下报错（缺少时间部分），JDK 11+ 默认补 T00:00；又比如 NumberFormat.getInstance().parse("1,234") 在不同 locale 下结果不同，硬编码 en_US 才可靠。
建议做法：
- 所有日期解析显式传
DateTimeFormatter，不用默认格式器 - 数值解析避免依赖系统 locale，改用
DecimalFormat配合Locale.ROOT - 对输入做最小预处理：trim 空格、判空、正则校验前置（比如邮箱转换前先
s.matches(".+@.+\..+")）
最常漏掉的是时区。把 long 时间戳转 LocalDateTime 时，必须明确它是 UTC 还是系统默认时区——少这一句 Instant.ofEpochMilli(ts).atZone(ZoneId.of("UTC"))，线上就可能出错八小时。
