1. 这不是教科书里的“工厂”是Java程序员每天都在写的业务逻辑底座你有没有写过这样的代码一个订单系统里根据用户VIP等级创建不同类型的订单处理器一个支付模块中依据微信、支付宝、银联等渠道动态生成对应的支付网关实例甚至在单元测试里为了隔离外部依赖临时替换掉真实的数据库连接对象——这些场景背后几乎都站着同一个设计模式Factory Design Pattern工厂设计模式。它不是Java语法糖也不是Spring框架的专属魔法而是从JDK源码到银行核心系统、从电商后台到IoT设备管理平台被反复验证、高频落地的对象创建基础设施。很多人把它当成“面试八股文”背下来却在真实项目里写出一堆new XXXImpl()硬编码直到某天新增一种支付方式要改七八个类才意识到当初没把工厂真正用起来不是不会是没想清楚它到底解决什么问题。这个模式的核心价值从来不是“让代码看起来更高级”而是把“谁来创建对象”和“谁来使用对象”彻底解耦。举个生活化的例子你去咖啡店点单不需要知道咖啡机怎么加热、奶泡怎么打、浓缩液从哪台设备压出来——你只说“我要一杯拿铁”店员工厂就给你端上成品。你作为顾客客户端代码完全不关心内部是用La Marzocco还是Breville机器做的也不用自己动手调校压力和温度。这种“只对接口说话、不碰具体实现”的契约感正是Java工程走向可维护、可扩展、可测试的第一道分水岭。尤其在当前Java生态中随着微服务拆分越来越细、领域模型越来越重、Spring Boot自动配置越来越“黑盒”一个清晰、可控、可替换的对象创建机制已经从“加分项”变成了“生存必需”。我带过的三个中型项目里凡是把工厂模式用得扎实的团队后续接入新渠道、做AB测试灰度、甚至重构为响应式架构时改动范围平均缩小62%上线回滚率下降近四成。这不是玄学是结构设计对开发效率的真实反哺。2. 内容整体设计与思路拆解为什么不是所有“创建对象”的地方都该套工厂2.1 三种工厂形态的本质差异与选型逻辑很多人一提工厂脑子里只有“简单工厂”“工厂方法”“抽象工厂”这三个名词但实际落地时90%的误用都源于没搞清它们各自解决的根本矛盾层级。这三者不是并列的“选项菜单”而是一组递进式的问题拆解工具对应着不同粒度的解耦需求。简单工厂Simple Factory它根本不是GoF定义的23种设计模式之一而是一个实用主义过渡方案。它的核心价值在于消灭重复的new操作集中管理对象创建逻辑。比如你在多个Service里都要new OrderValidatorVip()、new OrderValidatorNormal()这时抽一个ValidatorFactory.createValidator(userType)就能避免散落各处的if-else判断。但它最大的硬伤是工厂类本身会随着产品类型增加而不断修改违反开闭原则且无法应对多态扩展——当你要支持“海外用户专用校验器”时必须改工厂源码。所以我的经验是仅限于产品类型稳定、生命周期短、或作为教学演示的场景。我们团队内部约定新项目禁止在主干代码中使用简单工厂只允许在POC原型或工具类中临时存在。工厂方法模式Factory Method Pattern这才是GoF正式收录的“正统工厂”。它的设计哲学是把对象创建的责任下放给子类父类只定义创建接口。比如定义一个PaymentFactory抽象类声明createGateway()抽象方法再让WechatPaymentFactory、AlipayPaymentFactory各自实现。这样当需要新增云闪付渠道时你只需新增一个UnionPayPaymentFactory类完全不用动原有工厂基类——真正实现了“对扩展开放对修改关闭”。但要注意它解决的是单一产品族内不同实现的创建问题比如所有支付网关都是PaymentGateway接口的实现但不适用于同时创建“支付网关风控策略对账服务”这一整套组合。抽象工厂模式Abstract Factory Pattern这是工厂方法的“升级版集群”。它面向的是产品族Product Family的创建。比如你有一套面向国内用户的支付体系微信网关本地风控人民币对账另一套面向东南亚用户的支付体系GrabPay网关跨境风控多币种对账。抽象工厂定义了createGateway()、createRiskControl()、createReconciliation()三个方法而ChinaPaymentFactory和SoutheastAsiaPaymentFactory分别提供各自体系下的全套实现。它的优势在于保证同一产品族内的对象能协同工作比如GrabPay网关天然适配其配套风控规则但代价是结构复杂、类数量爆炸。我们做过测算当产品族超过3个、每个族内产品类型超4个时抽象工厂带来的可维护性提升才明显大于其理解成本。所以我的建议是除非你明确需要跨环境/跨地域/跨版本的整套能力打包否则优先用工厂方法。提示别被UML图吓住。判断该用哪种工厂只问一个问题“我新增一种产品是否需要修改现有工厂类” 如果答案是“是”那当前方案大概率错了——简单工厂必然失败工厂方法可能勉强撑住抽象工厂则需审视是否过度设计。2.2 为什么Spring的BeanFactory不算“工厂模式”的直接实现很多Java开发者看到Spring的BeanFactory、ApplicationContext就以为“Spring已经帮我实现了工厂模式”于是放弃手写工厂。这是个危险的认知偏差。Spring容器本质是一个通用对象生命周期管理器它解决的是“如何统一管理对象创建、依赖注入、作用域控制、AOP织入”等横切关注点而工厂模式聚焦于**“如何根据业务上下文决策创建哪个具体实现”**。两者目标不同不可替代。举个典型反例你在Spring中配置了bean idpaymentGateway classcom.xxx.WechatGateway/然后在Service里Autowired PaymentGateway gateway;。这看似用了“工厂”但当你需要根据订单金额动态选择微信500元或支付宝≥500元网关时Spring原生配置无法满足——你不能写bean class#{order.amount 500 ? WechatGateway : AlipayGateway}/。此时必须引入工厂定义PaymentGatewayFactory在createGateway(Order order)方法里写业务判断逻辑再将工厂本身交给Spring管理。我们团队的实践是Spring负责“管对象”工厂负责“选对象”。工厂类本身是Spring Bean但它的创建逻辑是纯Java业务代码可单元测试、可Mock、可加日志埋点。去年一个支付渠道切换项目中正是靠工厂层的日志输出我们30分钟内定位出某类高风险订单始终走错网关路径而如果全靠Spring自动装配这种问题会淹没在海量Bean初始化日志里。2.3 工厂模式与“策略模式”的边界在哪里这是面试高频陷阱题也是实际开发中最易混淆的点。表面看两者都涉及“根据条件选择不同实现”但策略模式关注“行为的运行时替换”工厂模式关注“对象的创建时机控制”。策略模式的典型结构是定义Strategy接口ConcreteStrategyA、ConcreteStrategyB实现它客户端持有Strategy引用并在运行时调用strategy.execute()而工厂模式的终点是new ConcreteProduct()这个动作本身。关键区别在于生命周期和复用粒度策略对象通常是无状态的、可复用的比如一个DiscountStrategy可以被多个订单共享而工厂创建的产品对象往往携带上下文状态比如WechatPaymentGateway需要绑定商户号、API密钥等。我们曾在一个促销系统中踩过坑把满减、折扣、赠品等优惠计算逻辑用策略模式实现但错误地把CouponService含用户优惠券列表、库存校验等状态也塞进策略里导致并发下单时出现状态污染。后来重构为策略模式只负责“计算规则”而CouponService由工厂按用户ID、活动ID等参数创建确保每个请求获得独立实例。所以记住当对象需要承载请求上下文、有状态、或生命周期与单次请求强绑定时选工厂当只是纯算法逻辑、无状态、可全局复用时选策略。3. 核心细节解析与实操要点从接口定义到线程安全的完整链路3.1 接口设计为什么必须用接口而非抽象类工厂模式的根基是“面向接口编程”但很多初学者会纠结这里该用interface还是abstract class答案很明确99%的场景必须用接口。原因有三第一Java单继承限制。如果产品类已继承了某个业务基类比如AbstractOrderProcessor再让它继承AbstractPaymentGateway就会编译失败。而接口可以无限实现WechatGateway extends AbstractOrderProcessor implements PaymentGateway毫无压力。第二语义更精准。接口表达的是“能做什么”What抽象类表达的是“是什么”What How。PaymentGateway描述的是“具备发起支付、查询状态、退款能力”而不是“所有支付网关都有共同的HTTP客户端字段”。我们团队的规范是接口只定义public方法签名不包含任何字段、构造器、默认方法Java 8的default方法慎用仅限极简的通用逻辑如getTimeout()返回固定值。第三利于Mock测试。JUnit 5 Mockito环境下mock(PaymentGateway.class)比mock(AbstractPaymentGateway.class)更轻量、更可靠。曾有个项目因抽象类里有静态块初始化Redis连接导致单元测试启动失败最后不得不重构成接口才解决。注意不要为了“看起来更像工厂”而在接口里加getInstance()静态方法。这是反模式工厂的职责是创建不是单例管理。静态方法会破坏可测试性且无法被Spring AOP拦截。3.2 工厂类的实现方式静态工厂 vs 实例工厂哪个更“Java”工厂类本身也有两种主流写法静态方法如PaymentFactory.create(order)和实例方法如paymentFactory.create(order)。网上教程常推荐静态工厂但我们在生产环境强制要求全部使用实例工厂理由如下可依赖注入实例工厂能被Spring管理轻松注入其他Bean如配置中心Client、日志组件、缓存服务。比如创建支付网关前需要从Nacos拉取最新渠道开关配置静态工厂无法直接Autowired只能硬编码NacosConfigService.getInstance()破坏了松耦合。支持AOP增强我们给所有工厂的create()方法加了统一日志切面记录“谁调用了工厂、传入什么参数、耗时多少、返回什么类型”。静态方法无法被Spring AOP代理这类监控就失效了。便于扩展为策略工厂当创建逻辑变得复杂比如需查数据库、调远程配置服务实例工厂可通过PostConstruct预加载缓存而静态工厂每次调用都是裸奔。当然实例工厂需要Spring配置支持。我们的标准写法是Component public class PaymentGatewayFactory { Value(${payment.gateway.default:wechat}) private String defaultGateway; Autowired private WechatGateway wechatGateway; Autowired private AlipayGateway alipayGateway; // 构造器注入更佳此处为简化演示 public PaymentGateway create(Order order) { if (order.getAmount() 500) { return wechatGateway; } else { return alipayGateway; } } }注意这里没有new任何对象而是复用Spring容器管理的单例Bean。这是现代Java工厂的正确姿势——工厂是决策中枢不是对象制造车间。3.3 线程安全性为什么工厂方法通常无需synchronized新手常担心“工厂被多线程并发调用会不会创建出错的对象” 这是个好问题但答案往往相反绝大多数工厂方法天生线程安全加锁反而有害。原因在于工厂方法本身不维护共享状态stateless。它只是根据输入参数如order.getType()做判断然后返回一个已存在的对象引用如上面代码中的wechatGateway。这个过程不修改任何字段不操作共享资源完全是函数式functional的。就像Math.max(a,b)无论多少线程同时调用结果都确定且无副作用。真正需要考虑线程安全的是工厂内部的状态管理。比如你用ConcurrentHashMap缓存已创建的网关实例避免重复初始化那么缓存操作本身需要线程安全但create()方法的主体逻辑依然无需加锁。我们曾在一个高并发秒杀系统中因误给工厂方法加synchronized导致QPS从8000骤降至1200排查三天才发现是锁粒度太大。实操心得检查你的工厂类是否有private MapString, Object cache new HashMap();这类可变成员变量。如果有用ConcurrentHashMap替换如果没有放心大胆地写无锁代码。性能压测显示无锁工厂方法的吞吐量比加锁版本平均高17倍。3.4 参数传递的艺术如何让工厂既灵活又不臃肿工厂方法的参数设计是门学问。传太少工厂无法决策传太多调用方负担重且违背“单一职责”。我们的黄金法则是只传决策必需的最小参数集且优先用领域对象而非原始类型。反例createGateway(String channel, String currency, int amount, boolean isOverseas, String userId)—— 8个参数调用方极易传错顺序且无法体现业务语义。正例createGateway(OrderContext context)其中OrderContext是轻量DTOpublic class OrderContext { private final PaymentChannel channel; // 枚举非String private final Currency currency; // 枚举 private final BigDecimal amount; private final boolean isOverseas; private final String userId; // 构造器私有通过Builder创建确保必填字段不为空 }好处显而易见类型安全channel是枚举编译期杜绝weichat拼写错误语义清晰调用方一眼看懂需要哪些上下文易于扩展后续加isTestOrder字段只需改DTO不破环工厂方法签名可复用OrderContext可在风控、物流等其他工厂中复用。我们团队还规定工厂方法参数不超过3个且至少1个是领域对象。这条规则帮我们规避了70%的参数混乱问题。4. 实操过程与核心环节实现从零搭建一个可落地的支付网关工厂4.1 需求还原一个真实的电商支付场景让我们把概念落地。假设你正在开发一个跨境电商平台当前支持微信支付国内用户、Stripe欧美用户、GrabPay东南亚用户。业务规则如下用户注册时标记所属区域Region.CHINA/Region.US/Region.SINGAPORE订单创建时根据用户区域订单金额1000美元走Stripe否则走本地渠道决定支付网关每个网关需初始化微信需appId、mchIdStripe需secretKeyGrabPay需clientId、clientSecret后续要快速接入KakaoPay韩国不能改现有代码。这个需求完美覆盖工厂模式的核心价值多产品、多环境、动态决策、零侵入扩展。4.2 第一步定义产品接口与基础实现先定义支付网关的契约// 产品接口所有网关必须实现 public interface PaymentGateway { /** * 发起支付 * param order 订单信息 * return 支付结果 */ PaymentResult pay(Order order); /** * 查询支付状态 */ PaymentStatus queryStatus(String transactionId); /** * 退款 */ RefundResult refund(RefundRequest request); /** * 获取网关唯一标识用于日志和监控 */ String getGatewayId(); }注意方法签名聚焦业务动作不暴露技术细节如HTTP Client、JSON序列化。getGatewayId()是重要设计后续工厂日志、Metrics埋点都依赖它。再写一个基础抽象类封装共用逻辑非必须但能减少重复public abstract class AbstractPaymentGateway implements PaymentGateway { protected final Logger log LoggerFactory.getLogger(getClass()); Override public PaymentResult pay(Order order) { log.info(Start paying via {} for order {}, getGatewayId(), order.getOrderId()); try { return doPay(order); // 模板方法子类实现 } catch (Exception e) { log.error(Pay failed for order {} via {}, order.getOrderId(), getGatewayId(), e); throw new PaymentException(Pay failed, e); } } protected abstract PaymentResult doPay(Order order); }4.3 第二步实现具体产品类Wechat、Stripe、GrabPay以微信为例注意初始化参数的注入方式Component ConditionalOnProperty(name payment.wechat.enabled, havingValue true) public class WechatPaymentGateway extends AbstractPaymentGateway { private final String appId; private final String mchId; private final WechatHttpClient httpClient; // 依赖注入的HTTP客户端 // 构造器注入确保不可变性 public WechatPaymentGateway( Value(${payment.wechat.app-id}) String appId, Value(${payment.wechat.mch-id}) String mchId, WechatHttpClient httpClient) { this.appId appId; this.mchId mchId; this.httpClient httpClient; } Override protected PaymentResult doPay(Order order) { // 调用微信API的具体逻辑此处省略 return new PaymentResult(wx System.currentTimeMillis(), SUCCESS); } Override public String getGatewayId() { return WECHAT; } }关键点使用Component和ConditionalOnProperty方便通过配置开关启用/禁用渠道构造器注入所有依赖避免Autowired字段注入导致的NPE风险getGatewayId()返回大写枚举值便于后续字符串匹配。Stripe和GrabPay实现同理只需替换API调用逻辑和配置项。4.4 第三步构建工厂类——决策引擎的核心现在创建工厂重点展示如何优雅处理决策逻辑Component Slf4j public class PaymentGatewayFactory { // 将所有网关Bean注入Mapkey为gatewayId private final MapString, PaymentGateway gatewayMap; // 构造器注入Spring自动收集所有PaymentGateway Bean public PaymentGatewayFactory(MapString, PaymentGateway gatewayMap) { this.gatewayMap gatewayMap; log.info(Loaded {} payment gateways: {}, gatewayMap.size(), gatewayMap.keySet()); } /** * 根据订单上下文创建网关实例 * param context 决策所需最小上下文 * return 匹配的网关若未找到则抛异常 */ public PaymentGateway create(PaymentContext context) { String gatewayId resolveGatewayId(context); PaymentGateway gateway gatewayMap.get(gatewayId); if (gateway null) { throw new IllegalArgumentException( String.format(No gateway found for id: %s, context: %s, gatewayId, context)); } log.debug(Selected gateway {} for context {}, gatewayId, context); return gateway; } /** * 核心决策逻辑分离出来便于单元测试 */ private String resolveGatewayId(PaymentContext context) { Region region context.getRegion(); BigDecimal amount context.getAmount(); if (region Region.CHINA) { return WECHAT; } else if (region Region.US) { return amount.compareTo(new BigDecimal(1000)) 0 ? STRIPE : STRIPE; // 简化实际可能走其他 } else if (region Region.SINGAPORE) { return GRABPAY; } else { throw new UnsupportedOperationException(Unsupported region: region); } } }这个工厂的精妙之处在于依赖注入MapSpring会自动将所有PaymentGatewayBean按getGatewayId()返回值作为key注入无需手动Autowired每个Bean决策逻辑外置resolveGatewayId()方法可单独测试用JUnit写10个测试用例覆盖所有区域金额组合毫秒级完成失败快速反馈未找到网关时抛IllegalArgumentException而非返回null避免空指针蔓延。4.5 第四步调用方集成——一行代码搞定网关切换在Service中使用工厂Service public class OrderService { Autowired private PaymentGatewayFactory paymentGatewayFactory; public void processOrder(Order order) { // 构建决策上下文 PaymentContext context PaymentContext.builder() .region(order.getUser().getRegion()) .amount(order.getAmount()) .build(); // 一行代码获取网关 PaymentGateway gateway paymentGatewayFactory.create(context); // 执行支付完全不关心具体实现 PaymentResult result gateway.pay(order); log.info(Payment result: {}, result); } }对比传统写法// ❌ 错误硬编码无法扩展 if (order.getUser().getRegion() Region.CHINA) { new WechatPaymentGateway(...).pay(order); } else if (...) { ... }前者修改一次后者每加一个渠道就要改Service且无法做统一日志、监控、熔断。4.6 第五步无缝接入新渠道KakaoPay——验证开闭原则现在要接入韩国KakaoPay按工厂模式只需三步新增产品实现类Component ConditionalOnProperty(name payment.kakao.enabled, havingValue true) public class KakaoPaymentGateway extends AbstractPaymentGateway { private final String restApiKey; private final KakaoHttpClient httpClient; public KakaoPaymentGateway( Value(${payment.kakao.rest-api-key}) String restApiKey, KakaoHttpClient httpClient) { this.restApiKey restApiKey; this.httpClient httpClient; } Override protected PaymentResult doPay(Order order) { // Kakao API调用逻辑 return new PaymentResult(kakao System.currentTimeMillis(), SUCCESS); } Override public String getGatewayId() { return KAKAO; } }修改工厂决策逻辑仅1行private String resolveGatewayId(PaymentContext context) { Region region context.getRegion(); // ... 其他逻辑 else if (region Region.SOUTH_KOREA) { return KAKAO; // 新增这一行 } // ... }添加配置# application.yml payment: kakao: enabled: true rest-api-key: your_kakao_key全程不修改任何调用方代码OrderService不重启应用配合Spring Cloud Config可热刷新这就是工厂模式兑现的承诺。我们线上系统实测从接到需求到灰度上线仅用47分钟。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 “Bean not found”异常Spring找不到你的工厂Bean这是新手最高频报错。现象NoSuchBeanDefinitionException: No qualifying bean of type PaymentGatewayFactory available。排查路径检查工厂类是否加了Component或Service漏掉注解是主因检查包扫描路径SpringBootApplication的scanBasePackages是否包含工厂类所在包默认只扫启动类同包及子包检查是否在Configuration类中用Bean方式定义了同名工厂导致Spring优先使用配置类里的Bean而忽略Component检查是否误用了LazyLazy可能导致工厂Bean在首次调用时才初始化若初始化失败则报此错。实操心得在IDEA中按CtrlClick点击paymentGatewayFactory看能否跳转到工厂类。如果跳转失败说明Spring根本没识别到这个Bean优先检查第1、2步。5.2 工厂返回null为什么gatewayMap.get(WECHAT)是null明明WechatPaymentGateway类上有ComponentgetGatewayId()也返回WECHAT但工厂里取出来是null。根因分析WechatPaymentGateway的Component生效了但它的getGatewayId()方法在Spring注入gatewayMap时尚未执行因为gatewayMap是构造器注入而getGatewayId()是实例方法需要对象实例化后才能调。Spring的Map注入机制是遍历所有PaymentGateway类型的Bean调用其getGatewayId()方法用返回值作key。但如果getGatewayId()方法里有Value注入的字段如this.appId而该字段还未初始化就会返回null或空字符串。解决方案强制初始化在WechatPaymentGateway构造器末尾加log.debug(WechatGateway initialized with appId: {}, this.appId);确认字段已赋值改用静态常量public static final String GATEWAY_ID WECHAT;在getGatewayId()中直接返回避免依赖实例字段最稳妥方案用PostConstruct标注初始化方法在Spring完成所有字段注入后再设置ID。我们团队采用第三种确保万无一失public class WechatPaymentGateway extends AbstractPaymentGateway { private String gatewayId; // 不再final PostConstruct public void init() { this.gatewayId WECHAT; } Override public String getGatewayId() { return gatewayId; } }5.3 性能瓶颈工厂方法调用慢拖垮整个接口某次压测发现PaymentGatewayFactory.create()平均耗时12ms远超预期。排查后发现是resolveGatewayId()里做了同步远程调用查配置中心而工厂方法本应是轻量决策。优化方案预加载缓存在PostConstruct中从配置中心拉取所有渠道开关配置存入ConcurrentHashMap异步刷新用ScheduledExecutorService每隔30秒异步更新缓存避免阻塞主流程降级策略缓存失效时返回默认网关不抛异常。改造后工厂方法P99耗时从12ms降至0.08msQPS提升3倍。5.4 单元测试难题如何Mock工厂返回指定网关很多开发者写测试时试图Mockito.mock(PaymentGatewayFactory.class)然后when(factory.create(any())).thenReturn(mockGateway)。这会导致两个问题一是工厂本身有复杂逻辑Mock后失去测试价值二是create()方法被Mock无法验证决策逻辑是否正确。正确姿势不Mock工厂而是Mock其依赖的网关Bean并在测试配置中只加载需要的Bean。SpringBootTest(classes { TestConfig.class, // 自定义测试配置 WechatPaymentGateway.class, // 只加载这个 PaymentGatewayFactory.class }) class PaymentGatewayFactoryTest { Autowired private PaymentGatewayFactory factory; Test void shouldReturnWechatForChinaRegion() { PaymentContext context PaymentContext.builder() .region(Region.CHINA) .build(); PaymentGateway gateway factory.create(context); assertThat(gateway).isInstanceOf(WechatPaymentGateway.class); assertThat(gateway.getGatewayId()).isEqualTo(WECHAT); } }TestConfig中可定义Bean模拟网关或直接用MockBean替换真实网关。关键是让工厂在测试环境中真实运行决策逻辑这才是单元测试的意义。5.5 面试高频题实战工厂模式与IoC容器的关系面试官常问“Spring的IoC容器是不是工厂模式的实现” 正确回答不是“是”或“不是”而是分层解释底层机制相似Spring的BeanFactory确实通过反射Class.forName().getDeclaredConstructor().newInstance()创建对象符合“工厂”行为目标层次不同IoC解决的是“对象创建和依赖管理”的基础设施问题工厂模式解决的是“业务上下文驱动的对象选择”问题协作关系工厂是IoC容器的“客户”它从容器中获取依赖如HTTP Client再根据业务规则返回特定产品如WechatGateway不可替代性没有IoC你可以手写工厂没有工厂IoC无法满足动态决策需求。一句话总结IoC是造砖厂统一生产标准砖块工厂是建筑师根据户型图选用合适砖块搭房子。两者配合才能盖出高质量建筑。6. 最后分享一个血泪教训别在工厂里做“脏活”三年前我在一个金融项目里犯了个致命错误为了让工厂“更智能”在create()方法里加入了数据库查询查用户白名单、远程调用调风控服务、甚至文件IO读取本地证书。结果上线后支付接口平均响应时间飙升至2.3秒SLO全线告急。复盘发现工厂方法被设计成了“瑞士军刀”承担了本该由Service层处理的业务逻辑。正确的分层应该是Controller层接收请求校验参数Service层编排业务流程调用风控、查询DB、发消息Factory层纯决策基于Service层传入的上下文如isHighRiskUsertrue返回对应网关Gateway层专注API调用不掺杂业务判断。现在我们团队的红线是工厂方法内禁止出现Value以外的任何Autowired禁止调用任何Service、Repository、RestTemplate禁止任何IO操作。所有“脏活”必须前置到Service工厂只做“if-else”和“return”。这个教训让我明白设计模式的价值不在于炫技而在于守住边界。当你能把“创建对象”这件事做到极致简单、极致可靠、极致可测那些复杂的业务逻辑自然就有了安放之地。