Spring 里怎么用設(shè)計(jì)模式先看變化點(diǎn)再組責(zé)任鏈設(shè)計(jì)模式解決的是反復(fù)出現(xiàn)的變化不是if-else的替代品。只有兩三個穩(wěn)定分支時直接寫清判斷通常更容易讀變化維度獨(dú)立、規(guī)則會持續(xù)增加時策略或責(zé)任鏈才值得引入。這篇文章從這條邊界出發(fā)檢查 Spring 項(xiàng)目里常見模式的使用條件、線程安全和失敗路徑。flowchart TD subgraph SpringAutoAssembly [Spring 容器自動裝配 策略責(zé)任鏈組合體系] SpringContext[Spring ApplicationContext] --|1. 自動注入 MapString, PayStrategy| StrategyMap[策略映射容器 (PayStrategyMap)] ClientReq[支付請求 (type: ALIPAY)] -- StrategyMap StrategyMap --|2. O(1) 路由查找| AliPayNode[AliPayStrategy 節(jié)點(diǎn)] subgraph ChainExecution [責(zé)任鏈安全執(zhí)行器 (Chain Engine)] AliPayNode --|3. 節(jié)點(diǎn)遞進(jìn) (Max Depth 10)| RiskNode[風(fēng)控校驗(yàn)節(jié)點(diǎn)] RiskNode --|4. 超時防線 (Timeout 200ms)| LimitNode[限額校驗(yàn)節(jié)點(diǎn)] LimitNode --|5. 執(zhí)行扣款| Execution[第三方 Channel 扣款] end end1. 經(jīng)典模式的反例與使用邊界1.1 策略模式Strategy Pattern?反例業(yè)務(wù)邏輯極其固定全系統(tǒng)中僅有“VIP 用戶”與“普通用戶”兩種 9.5 折計(jì)算且未來絕不會增加其他類型。有的開發(fā)者強(qiáng)行寫了DiscountStrategy接口、VipDiscountStrategy類、NormalDiscountStrategy類再搭配一個StrategyFactory類。修改一個折扣參數(shù)要打開 5 個文件。?適用條件與邊界業(yè)務(wù)分支數(shù)量大于等于 4 個且屬于高度不穩(wěn)定的頻發(fā)變更項(xiàng)如支付渠道接入、不同電商節(jié)日的營銷扣減計(jì)算。必須能與 Spring 容器的MapString, Strategy自動注入機(jī)制天然結(jié)合避免手動寫硬編碼的Factory類。1.2 責(zé)任鏈模式Chain of Responsibility Pattern?反例責(zé)任鏈節(jié)點(diǎn)未設(shè)置深度上限Max Chain Depth與超時控制。當(dāng)鏈路節(jié)點(diǎn)達(dá)到幾十個或者發(fā)生循環(huán)節(jié)點(diǎn)引用時直接引發(fā)java.lang.StackOverflowError。在并發(fā)請求下一個節(jié)點(diǎn)的卡死會導(dǎo)致整條責(zé)任鏈持有的線程無法釋放。我們在終端中使用jstack診斷責(zé)任鏈過深引發(fā)的堆棧溢出或卡死日志jstack 68201 | grep -E at com.example.pattern.chain | head -n 12終端控制臺日志輸出展示at com.example.pattern.chain.RiskCheckHandler.handle(RiskCheckHandler.java:34) at com.example.pattern.chain.LimitCheckHandler.handle(LimitCheckHandler.java:28) at com.example.pattern.chain.AuthCheckHandler.handle(AuthCheckHandler.java:28) ... (重復(fù) 100 次) java.lang.StackOverflowError: Recursion depth exceeded safety threshold針對這個問題責(zé)任鏈模式在生產(chǎn)環(huán)境中必須包含遞歸深度硬限制與單節(jié)點(diǎn) Execution Timeout 保護(hù)。2. 生產(chǎn)級Spring 容器裝配與安全責(zé)任鏈代碼下面是在 Spring Boot 框架下結(jié)合MapString, Strategy自動裝配與包含深度防線的責(zé)任鏈生產(chǎn)實(shí)現(xiàn)代碼package com.example.pattern.production; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.stereotype.Component; import org.springframework.stereotype.Service; import java.util.List; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; // 1. 定義策略接口 public interface PaymentStrategy { String getChannelType(); boolean processPayment(PaymentContext context); } // 2. 策略實(shí)現(xiàn)類 1支付寶 Component class AlipayStrategy implements PaymentStrategy { Override public String getChannelType() { return ALIPAY; } Override public boolean processPayment(PaymentContext context) { // 執(zhí)行支付寶專用扣款邏輯 return true; } } // 3. 策略實(shí)現(xiàn)類 2微信支付 Component class WechatPayStrategy implements PaymentStrategy { Override public String getChannelType() { return WECHAT; } Override public boolean processPayment(PaymentContext context) { // 執(zhí)行微信專用扣款邏輯 return true; } } // 4. 生產(chǎn)級安全策略工廠與責(zé)任鏈調(diào)度中樞 Service public class PaymentEngineService { private static final Logger log LoggerFactory.getLogger(PaymentEngineService.class); private static final int MAX_CHAIN_DEPTH 8; // 安全深度上限防護(hù) // Spring 會自動將所有實(shí)現(xiàn) PaymentStrategy 的 Bean 收集并注入到這個 Map 中 private final MapString, PaymentStrategy strategyMap new ConcurrentHashMap(); public PaymentEngineService(ListPaymentStrategy strategies) { for (PaymentStrategy strategy : strategies) { this.strategyMap.put(strategy.getChannelType(), strategy); log.info(已自動裝配支付策略節(jié)點(diǎn): [{}] - {}, strategy.getChannelType(), strategy.getClass().getSimpleName()); } } public boolean executePayment(String channelType, PaymentContext context) { PaymentStrategy strategy strategyMap.get(channelType); if (strategy null) { throw new IllegalArgumentException(未找到匹配的支付策略渠道: channelType); } // 校驗(yàn)責(zé)任鏈執(zhí)行深度防護(hù) if (context.getExecutionDepth() MAX_CHAIN_DEPTH) { log.error( 責(zé)任鏈遞歸深度 ({} ) 超過安全上限 ({})強(qiáng)行攔截阻斷!, context.getExecutionDepth(), MAX_CHAIN_DEPTH); throw new IllegalStateException(責(zé)任鏈執(zhí)行深度溢出); } context.incrementDepth(); return strategy.processPayment(context); } } // 上下文傳遞對象 class PaymentContext { private int executionDepth 0; public int getExecutionDepth() { return executionDepth; } public void incrementDepth() { this.executionDepth; } }模式是否值得用取決于變化是否真實(shí)存在。引入策略或責(zé)任鏈前先寫清新增規(guī)則的頻率、執(zhí)行順序、失敗處理和可觀測點(diǎn)這些條件不成立時普通分支往往更合適。