应使用静态方法实现通用数据转换工具，因其不依赖状态、无副作用、避免对象创建开销；需定义final类、私有构造函数、public static方法，按严格/宽松/函数式分档设计，并显式处理日期格式、数字locale及输入不可变性。
直接用静态方法实现通用数据转换工具，核心是把“不依赖状态、无副作用”的逻辑封装成 public static 方法，并通过合理设计覆盖常见使用场景。
为什么选静态方法而不是实例化类
字符串转数字、时间戳转 LocalDateTime、byte[] 与 hex 字符串互转——这类操作不读取对象字段、不修改外部状态、不依赖上下文。每次调用都是独立计算。如果非要 new 一个 Converter 实例，不仅多占内存，还让调用方困惑：“我只转一次，为什么要构造对象？”
- 避免无谓的对象创建和 GC 压力
- 调用简洁：DateConverters.parse("2025-06-19", DateTimeFormatter.ISO_DATE) 而非 new DateConverters().parse(...)
- 语义清晰：工具类名（如 NumberUtils、HexConverters）本身已说明用途，无需实例生命周期管理
静态工具类的规范写法
不是所有带 static 的类都算合格工具类。IDE 和团队规范通常要求：
- 类声明为 final，防止被继承
- 提供私有空构造函数：private NumberUtils() {}，杜绝 new 调用
- 所有方法为 public static，参数和返回值优先用不可变类型（String、long、LocalDateTime、BigDecimal）
- 命名统一：以 Utils 或 Converters 结尾，如 StringUtils、JsonConverters
漏掉私有构造函数，反射或测试中可能触发 java.lang.InstantiationError；不加 final，子类可能意外覆写行为，破坏工具类契约。
立即学习“Java免费学习笔记（深入）”；
转换方法要分档设计，不能只提供一种入口
“能转”不等于“好用”。同一个字符串转整数，业务需要可能完全不同：
- 严格模式：parseLong(String s) —— null 或格式错误直接抛 NumberFormatException，适合参数校验阶段
- 宽松模式：parseLong(String s, long defaultValue) —— 异常时返回默认值（注意别用 -1 或 0 这类易与正常值混淆的值）
- 函数式风格：tryParseLong(String s) → Optional<Long> —— 把“是否成功”显式交由调用方处理，适合链式调用或空值敏感流程
Optional 有轻微对象分配开销，但远低于 try-catch 控制流程；高吞吐服务可权衡是否启用。
绕不开的边界与兼容性细节
看似简单的转换，常在 JDK 升级或跨环境部署时出问题：
- 日期解析：LocalDateTime.parse("2025-06-19") 在 JDK 8 报错（缺时间部分），JDK 11+ 自动补 T00:00 —— 解决方案：永远显式传
DateTimeFormatter，不用默认解析器 - 数字格式：NumberFormat.getInstance().parse("1,234") 在中文 locale 下解析失败 —— 解决方案：用
DecimalFormat配合Locale.ROOT，确保行为一致 - 输入污染：接收 List<String> 后直接修改它？应先 copy 或用 Collections.unmodifiableList 包装，避免外部篡改影响结果
