静态工厂方法是轻量级解耦起点，通过封装创建逻辑使客户端仅依赖接口和工厂类，不直接调用new；它适合无状态、简单参数场景，但新增产品需修改工厂类，违反开闭原则。
静态方法本身不直接解耦，但当它被用作工厂入口时，就能把对象创建逻辑集中管理，从而切断客户端与具体实现类的硬依赖。关键不在“静态”，而在“封装创建过程”。
静态工厂方法：最轻量的解耦起点
它就是一个带名字的静态方法，返回接口类型对象，内部用 new 或反射创建实现类实例。客户端只依赖接口和工厂类，不碰任何 new XxxImpl()。
- 定义统一接口（如
PaymentService），声明行为规范 - 编写多个实现类（
AlipayService、WechatService），各自封装细节 - 在工厂类中写静态方法（如
PaymentFactory.create("alipay")），根据参数返回对应实现 - 业务代码调用时只写
PaymentService ps = PaymentFactory.create("alipay");，完全不知道底层是谁
为什么用静态方法而不是普通工厂对象？
静态工厂适合无状态、无需生命周期管理的场景，启动快、调用直，比如工具类、配置驱动的简单服务选型。它省去了工厂实例的创建和传递，降低使用门槛。
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
- 避免每次都要
new PaymentFactory()再调方法 - 天然单例语义，不需要额外控制实例数量
- 配合配置文件（如 properties）可做到运行时切换实现，改个字符串就换支付渠道
- 注意：过度使用会导致工厂类膨胀，新增实现就得改静态方法——这是它和工厂方法模式的本质区别
结合接口+静态工厂的真实解耦效果
假设登录验证模块要支持数据库、Redis、LDAP三种校验方式。若直接 new DbLoginDao()，所有调用处都得跟着改；而用静态工厂后：
- 接口
LoginDao不变，三个实现类各自独立演进 - 工厂方法
LoginDaoFactory.getDao("redis")封装了 new 和初始化逻辑 - Service 层代码完全不感知数据源变化，只需传入类型标识
- 测试时可轻松 mock 工厂返回值，或替换为内存实现做单元验证
进阶提醒：静态工厂不是终点
当产品种类变多、创建逻辑复杂（比如需依赖注入、连接池、上下文参数），静态工厂会力不从心。这时该升级到工厂方法模式或 Spring 的 FactoryBean。
- 静态工厂适合“少量、稳定、参数简单”的场景
- 若需按环境动态决定工厂、支持 AOP 增强创建过程、或集成 IoC 容器，就该让位给更结构化的方案
- 但别低估它——很多 Spring Boot Starter 底层仍用静态工厂加载默认组件，简洁有效才是工程首选
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
