静态方法作为工具方法存在可测试性差、隐含副作用、阻碍依赖注入、职责混乱四大局限，仅适用于无外部依赖的纯计算场景。
静态方法实现工具方法看似方便，实际在工程实践中存在几个关键局限，直接影响可测试性、可扩展性和系统演进。
难以 mock 和单元测试
静态方法调用是硬编码的，编译期绑定，无法在测试中替换行为。比如 DateUtils.format(Instant) 内部直接调用 DateTimeFormatter，一旦它依赖系统时区或真实时间，就无法控制输入输出。测试时没法模拟“昨天”“节假日”等场景，也没法验证是否误调用了外部服务（如日志记录、监控上报）。
- JUnit 5 + Mockito 默认不支持 mock 静态方法（需额外插件如 Mockito Inline，且有兼容风险）
- 若工具方法又调用了另一个静态方法（如
ConfigReader.getTimeout()），整个调用链变成黑盒，测试覆盖率断层
隐含全局状态与副作用
静态方法虽宣称“无状态”，但容易悄悄引入不可见依赖：读配置、访问静态缓存、写日志、发通知、修改 static 变量等。这类行为破坏了纯函数特性，导致相同输入可能产生不同输出，或引发并发问题。
- 例如
FileUtils.save(String path, byte[] data)看似工具方法，实则执行 I/O —— 这不是工具，是业务操作 -
IdGenerator.nextId()若内部用static long counter，多线程下不加同步会出错；加了同步又成性能瓶颈
阻碍面向接口编程和依赖注入
Spring 等主流框架基于接口和依赖注入构建松耦合架构。而静态方法绕过 DI 容器，无法被代理、增强（如事务、重试、熔断）、也无法按 profile 切换实现。
- 你不能把
HashUtils.encode()替换成测试用的DummyHasher，也不能在灰度环境启用新算法 - 当需要将本地加密升级为调用远程密钥服务时，静态方法必须全量改写，无法渐进式替换
命名与职责易失控
工具类天然倾向“什么都能放”，导致 CommonUtils 越来越臃肿，方法语义模糊、参数含义不清、异常处理随意。
-
Util.process(Object obj)不知道是序列化、校验还是转换 - 多个团队往同一个
StringUtils里加方法，出现isBlank()、isEmpty()、isNullOrEmpty()语义重叠甚至行为不一致 - 无法对某类工具方法统一加监控埋点或统一异常包装
不复杂但容易忽略：静态工具方法适合短生命周期、确定性高、无外部依赖的纯计算场景；一旦涉及配置、I/O、时间、网络或未来可能变化的逻辑，就该交给接口+实现+DI 来承载。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
