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