Spring中为何将无状态过程式方法封装为Bean而非使用静态方法？

你观察到的现象非常准确：Spring默认管理的Service、Repository层Bean绝大多数都是单例、无状态的，单看方法逻辑确实和工具类的静态方法很像，但工程上选择实例Bean而非静态方法，完全是出于实际开发维护的成本考量，和“纯OOP信仰”没什么关系，核心原因有这几个：

• 可测试性的本质差异
  静态方法的调用关系是编译期硬绑定的，你没法在运行时随意替换实现。举个最常见的场景：你写单元测试测OrderService的下单逻辑，不想真的连数据库查用户、扣库存，要把Repository层的调用mock成返回测试数据。如果Repository全是静态方法，你要么得改业务代码加判断逻辑区分测试环境，要么就得引入PowerMock这类会修改字节码的工具，测试启动慢、兼容问题多，平白增加大量测试成本。而Spring管理的实例Bean本身就是基于依赖注入的，测试时直接把Mock实现塞进去就行，不需要改任何业务代码。
• 无法适配基于动态代理的框架能力
  Spring的核心能力，比如声明式事务@Transactional、接口权限校验、统一日志切面、异常统一处理，全都是基于动态代理实现的：容器启动时会给原始Bean生成代理子类，在方法调用前后织入通用逻辑。静态方法属于类本身，没法通过继承或者接口实现的方式被代理，硬要给静态方法织入逻辑就得去改类加载时的字节码，复杂度极高、兼容性极差，根本没法做通用的框架支持。
• 面向抽象编程的灵活性要求
  静态方法没法实现接口，也不支持多态。举个很常见的业务场景：最开始你的项目用MySQL存数据，Repository层用MyBatis实现，后来要做合规改造，部分数据要存到MongoDB，要是全写的静态方法，你得把项目里所有调用Repository静态方法的地方全改一遍。如果是基于接口注入的Bean，你只需要写一套MongoDB的Repository实现类，调整下Bean的注入优先级，上层Service的代码一行都不用改。
• 生命周期与状态管理的成本问题
  你现在看到这些类无状态，不代表后续迭代不会加状态：比如要加限流阈值、开关配置、外部SDK客户端实例这类字段，如果用静态方法，你就得自己维护静态变量，处理类加载顺序、并发更新可见性、资源销毁回收这些问题，很容易踩静态块初始化顺序不对导致NPE、静态变量内存泄漏这类坑。而Spring管理的Bean有完整的生命周期回调，从对象创建、依赖注入、配置初始化到销毁回收全有标准流程，哪怕你要加状态字段，直接用注解注入就行，不用自己踩类加载的坑。而且默认单例的Bean和静态类的内存开销几乎没有差别，根本不存在浪费资源的问题。

别信什么“用实例方法就是纯OOP，用静态方法就是过程式”的教条，工程设计从来都是看实际收益：JDK里的Collections、通用工具类里的字符串判空、集合拷贝这类纯逻辑、无外部依赖、实现永远不会变的方法，本来就该用静态方法；但Service、Repository这类要对接外部资源、逻辑会随业务迭代、需要适配框架通用能力的代码，用容器管理的实例Bean，长期维护成本要比全写静态方法低得多。

内容的提问来源于stack exchange，提问作者Islam Khabibullin