Java工具类创建标准：静态方法与依赖注入方案对比

这确实是日常开发里很常见的纠结点！我来结合自己和身边团队的实践，聊聊几种工具类的创建方案，以及各自的适用场景：

1. 传统静态工具类（你提到的Utils模式） #

• 优势：调用起来特别省心，不用实例化，代码简洁直观。非常适合那些纯无状态、不依赖任何外部资源的通用方法——比如字符串拼接处理、日期格式化、简单的数学计算这类逻辑。
• 劣势：正如你所说，单元测试时根本没法mock静态方法，一旦工具类本身出了bug，所有依赖它的测试都会跟着失败；而且如果后续工具类需要引入其他依赖（比如要调用某个配置服务），静态写法会瞬间变得耦合度极高，维护起来特别头疼，我见过不少团队一开始用这种模式，后来不得不重构的情况。

2. 实例化工具类+构造注入 #

• 优势：完美解决了测试mock的痛点！单元测试时，你可以轻松传入一个mock的工具类实例，把依赖完全隔离开；同时这种写法更贴合面向对象的设计思路，如果工具类需要依赖其他组件（比如配置信息、其他服务），直接通过注入引入就行，扩展性强很多。
• 小提示：如果工具类本身是无状态的，可以把它设为单例——比如在Spring里用@Component默认的单例模式，或者手动实现单例逻辑，这样既享受到了可注入的好处，又不会有频繁创建实例的开销。

3. 更灵活的进阶方案：接口定义+实现类 #

如果你的工具方法可能有多种实现场景（比如不同业务场景需要不同的日期格式化规则），可以先定义一个接口来规范方法：

public interface DateFormatter {
    String format(LocalDate date);
}

再写具体的实现类：

public class IsoDateFormatter implements DateFormatter {
    @Override
    public String format(LocalDate date) {
        return DateTimeFormatter.ISO_LOCAL_DATE.format(date);
    }
}

之后在需要使用的类里注入DateFormatter接口就行。这样不仅测试时能轻松mock接口，后续要替换实现也只需要换个注入的实例，完全符合开闭原则，扩展性拉满。

最后给个选择小原则 #

• 如果是纯通用、无依赖、逻辑几乎不会变动的工具方法，静态工具类完全没问题；
• 如果工具方法需要依赖外部资源、需要做测试隔离，或者未来有扩展需求，优先选实例化+依赖注入，甚至接口化的方式。

内容的提问来源于stack exchange，提问作者tomer.z