重要设计模式一览

构建复杂的软件系统时，仅仅让代码“能运行”是不够的。随着系统扩展和需求演进，对象创建结构混乱、紧耦合、硬编码控制流以及静态继承层级会造成脆弱的架构。

本综合指南将剖析五种核心设计模式——Abstract Factory、Strategy、Adapter、Observer 和 Decorator，并结合真实的企业场景、反模式、权衡分析以及重构步骤。

---

📊 软件设计模式快速参考速查表

模式	类别	核心意图	真实场景	主要优势	主要架构权衡
Abstract Factory	创建型	无需指定具体类即可创建相关对象族。	多层级服务套餐（如基础版 vs. 精英税务套餐）。	消除产品族不匹配问题；强制统一的对象创建。	接口数量激增，间接调用开销较大。
Strategy	行为型	将可互换算法封装在统一接口后。	多支付网关路由器（Stripe、PayPal、Adyen）。	移除臃肿的 if-else/switch 块；遵循开闭原则。	简单算法变体也需创建多个类/模块。
Adapter	结构型	在两个不兼容接口之间进行转换。	集成遗留厂商 KYC SDK 的入驻服务。	将领域逻辑与外部/遗留 API 变更隔离。	数据映射开销及潜在的抽象泄露。
Observer	行为型	定义一对多依赖，将状态变更广播给订阅者。	电商订单结账事件通知。	将领域核心与下游副作用解耦。	执行流程不透明，调试与追踪困难。
Decorator	结构型	在运行时动态为对象添加行为，而不改变类结构。	带可选欺诈检测和审计功能的支付处理管道。	避免子类排列爆炸；支持动态组合。	破坏对象身份（== 检查失效）；运行时顺序依赖风险。

---

1. 抽象工厂模式

核心概念

Abstract Factory 模式为创建一组相关或相互依赖的对象提供接口，而无需指定具体类。它确保属于同一产品族的对象被一致地实例化，并将创建逻辑与客户端代码解耦。

场景：分层税务服务套餐

假设某服务商提供两种服务套餐：

1. 税务申报服务：基础版（标准 W-2） vs. 精英版（多州、加密货币、股票期权）。
2. 税务筹划服务：基础版（401k 建议） vs. 精英版（遗产规划及离岸避税）。

❌ 违背架构：分散实例化及产品族错配风险

在业务逻辑中直接实例化具体产品会引入人为错误——开发者可能意外地将 BasicTaxFiling 服务与 EliteTaxSaving 服务混用。

public class TaxServiceOrchestrator {

    public void executeService(String tier) {
        TaxFilingService filing;
        TaxSavingService saving;

        // 容易出错：开发者可能将 BASIC 申报与 ELITE 筹划混用
        if ("BASIC".equalsIgnoreCase(tier)) {
            filing = new BasicTaxFiling();
            saving = new BasicTaxSaving();
        } else if ("ELITE".equalsIgnoreCase(tier)) {
            filing = new EliteTaxFiling();
            saving = new EliteTaxSaving();
        } else {
            throw new IllegalArgumentException("Invalid service tier: " + tier);
        }

        filing.fileTaxes();
        saving.provideAdvice();
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ 重构架构：抽象工厂强制约束

结构架构图

graph TD
    subgraph Client Code
        Orchestrator[TaxServiceOrchestrator]
    end

    subgraph Factory Hierarchy
        FactoryInterface[FullServicePackageFactory Interface]
        BasicFactory[BasicPackageFactory]
        EliteFactory[ElitePackageFactory]

        FactoryInterface <|-- BasicFactory
        FactoryInterface <|-- EliteFactory
    end

    subgraph Product Families
        FilingInterface[TaxFilingService]
        SavingInterface[TaxSavingService]

        BasicFiling[BasicTaxFiling]
        EliteFiling[EliteTaxFiling]
        BasicSaving[BasicTaxSaving]
        EliteSaving[EliteTaxSaving]

        FilingInterface <|-- BasicFiling
        FilingInterface <|-- EliteFiling
        SavingInterface <|-- BasicSaving
        SavingInterface <|-- EliteSaving
    end

    Orchestrator --> FactoryInterface
    BasicFactory ..> BasicFiling
    BasicFactory ..> BasicSaving
    EliteFactory ..> EliteFiling
    EliteFactory ..> EliteSaving

Enter fullscreen mode Exit fullscreen mode

代码实现

// 1. 抽象产品 1：税务申报
public interface TaxFilingService {
    void fileTaxes();
}

// 2. 抽象产品 2：税务筹划
public interface TaxSavingService {
    void provideAdvice();
}

// 3. 基础套餐的具体产品
public class BasicTaxFiling implements TaxFilingService {
    @Override
    public void fileTaxes() { 
        System.out.println("Filing standard W-2 income taxes."); 
    }
}

public class BasicTaxSaving implements TaxSavingService {
    @Override
    public void provideAdvice() { 
        System.out.println("Providing basic 401(k) contribution advice."); 
    }
}

// 4. 精英套餐的具体产品
public class EliteTaxFiling implements TaxFilingService {
    @Override
    public void fileTaxes() { 
        System.out.println("Filing multi-state, crypto, and stock-option taxes."); 
    }
}

public class EliteTaxSaving implements TaxSavingService {
    @Override
    public void provideAdvice() { 
        System.out.println("Providing estate planning and offshore tax shelter advice."); 
    }
}

// 5. 抽象工厂接口
public interface FullServicePackageFactory {
    TaxFilingService createFilingService();
    TaxSavingService createSavingService();
}

// 6. 具体工厂 1：基础套餐族
public class BasicPackageFactory implements FullServicePackageFactory {
    @Override
    public TaxFilingService createFilingService() { 
        return new BasicTaxFiling(); 
    }

    @Override
    public TaxSavingService createSavingService() { 
        return new BasicTaxSaving(); 
    }
}

// 7. 具体工厂 2：精英套餐族
public class ElitePackageFactory implements FullServicePackageFactory {
    @Override
    public TaxFilingService createFilingService() { 
        return new EliteTaxFiling(); 
    }

    @Override
    public TaxSavingService createSavingService() { 
        return new EliteTaxSaving(); 
    }
}

// 8. 干净的客户端代码（保证产品族一致，零混用风险）
public class TaxOrchestrator {
    private final TaxFilingService filingService;
    private final TaxSavingService savingService;

    // 注入同一产品族的工厂
    public TaxOrchestrator(FullServicePackageFactory packageFactory) {
        this.filingService = packageFactory.createFilingService();
        this.savingService = packageFactory.createSavingService();
    }

    public void runFullService() {
        filingService.fileTaxes();
        savingService.provideAdvice();
    }
}

Enter fullscreen mode Exit fullscreen mode

为什么需要它？

• 消除具体耦合：将业务逻辑与具体产品类解耦。
• 可扩展性：新增产品线/套餐无需修改客户端业务代码。
• 防止产品混用：强制同一工厂创建的对象属于同一产品族。
• SOLID 对齐：遵循开闭原则和依赖倒置原则。

架构权衡

• 间接调用开销：开发者需穿越多层接口和工厂抽象才能查看具体实现。
• 接口激增：需为工厂及每条产品线创建抽象接口。

何时应避免或拒绝使用

• 简单不变对象：为简单 POJO、DTO 或具备标准构造器的领域实体创建工厂属于过度设计。
• IoC/DI 框架使用：现代框架（如 Spring、NestJS、Wire）已充当全局 IoC 容器。为由 DI 容器管理的单例服务编写自定义抽象工厂是多余的。

---

2. 策略模式

核心概念

Strategy 模式将算法选择与算法执行解耦。不再在核心业务逻辑中嵌入复杂条件引擎，而是将每种算法变体封装在公共接口之后。

场景：多网关支付路由器

支付路由系统需根据用户上下文或地区，通过不同支付提供商（Stripe、PayPal、Adyen）处理交易。

❌ 违背架构：条件单体

public class PaymentProcessor {

    public PaymentResult processPayment(String gateway, BigDecimal amount, PaymentInfo info) {
        if ("STRIPE".equalsIgnoreCase(gateway)) {
            // 50 行 Stripe SDK 调用、头设置及签名生成
            System.out.println("Processing via Stripe SDK...");
            return new PaymentResult(true, "ch_stripe_123");
        } else if ("PAYPAL".equalsIgnoreCase(gateway)) {
            // 60 行 PayPal OAuth 令牌获取及负载映射
            System.out.println("Processing via PayPal REST API...");
            return new PaymentResult(true, "pay_paypal_456");
        } else if ("ADYEN".equalsIgnoreCase(gateway)) {
            // 40 行 Adyen HMAC 签名生成及请求构建
            System.out.println("Processing via Adyen API...");
            return new PaymentResult(true, "adyen_tx_789");
        } else {
            throw new IllegalArgumentException("Unsupported payment gateway: " + gateway);
        }
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ 重构架构：封装策略注册表

graph LR
    Client[PaymentService] --> Registry[PaymentRegistry]
    Registry --> StrategyInterface[PaymentStrategy Interface]
    StrategyInterface <|.. Stripe[StripeStrategy]
    StrategyInterface <|.. PayPal[PayPalStrategy]
    StrategyInterface <|.. Adyen[AdyenStrategy]

Enter fullscreen mode Exit fullscreen mode

代码实现

// 1. 通用策略接口
public interface PaymentStrategy {
    void pay(double amount);
}

// 2. 具体策略 A
public class StripeStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        // Stripe API 特定逻辑
        System.out.println("Paid $" + amount + " using Stripe.");
    }
}

// 具体策略 B
public class PayPalStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        // PayPal API 特定逻辑
        System.out.println("Paid $" + amount + " using PayPal.");
    }
}

// 3. 简单策略注册表
public class PaymentRegistry {
    private final Map<String, PaymentStrategy> strategies = new HashMap<>();

    public PaymentRegistry() {
        // 按键注册策略
        strategies.put("STRIPE", new StripeStrategy());
        strategies.put("PAYPAL", new PayPalStrategy());
    }

    public PaymentStrategy get(String type) {
        PaymentStrategy strategy = strategies.get(type.toUpperCase());
        if (strategy == null) {
            throw new IllegalArgumentException("Invalid payment type: " + type);
        }
        return strategy;
    }
}

// 4. 客户端代码
public class PaymentService {
    private final PaymentRegistry registry = new PaymentRegistry();

    public void processPayment(String gatewayType, double amount) {
        // 获取匹配策略并执行
        PaymentStrategy strategy = registry.get(gatewayType);
        strategy.pay(amount);
    }

    public static void main(String[] args) {
        PaymentService service = new PaymentService();
        service.processPayment("STRIPE", 100.0); // 输出：Paid $100.0 using Stripe.
        service.processPayment("PAYPAL", 50.0);   // 输出：Paid $50.0 using PayPal.
    }
}

Enter fullscreen mode Exit fullscreen mode

为什么需要它？

• 消除控制流膨胀：用查找机制替换复杂的 if-else 或 switch 块。
• 隔离测试：可单独对每种算法进行单元测试，无需实例化周边服务。
• 遵循开闭原则：新增集成（如 NetBankingStrategy）只需添加类并注册。

架构权衡

• 类/模块爆炸：用多个具体策略类、注册表和接口契约替换单一多分支文件。

何时应避免或拒绝使用

• 不变/简单逻辑：若变体简单且极少变更，标准条件语句已足够。
• 函数式编程范式：在具备一等函数的语言（如 TypeScript、Rust、Go、现代 Java）中，为策略创建繁重的类层次结构属于反模式。传递 lambda 或高阶函数更优。

---

3. 适配器模式

核心概念

Adapter 模式充当不兼容接口之间的结构型翻译器。它让核心领域契约保持干净，同时在第三方 API 或遗留系统之间转换请求。

场景：KYC 身份验证集成

入驻服务需要第三方 KYC 身份验证，使用遗留外部厂商 SDK（LegacyPersonaSdk）。

❌ 违背架构：领域被外部契约污染

// 遗留厂商类（不可修改的外部 SDK）
class LegacyPersonaSdk {
    public int executeCheck(String passportNum, String countryIso2) {
        // 200 表示通过，401 表示失败，500 表示错误
        System.out.println("Calling Legacy Persona API...");
        return 200;
    }
}

// 违背业务逻辑：直接与厂商特定参数及状态码耦合
public class OnboardingService {
    private final LegacyPersonaSdk legacySdk = new LegacyPersonaSdk();

    public boolean verifyUser(String passportNumber, String countryCode) {
        // 直接耦合遗留方法签名及厂商状态码
        int responseCode = legacySdk.executeCheck(passportNumber, countryCode);
        return responseCode == 200;
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ 重构架构：领域适配器隔离

graph LR
    Client[OnboardingService] --> TargetInterface[KycVerifier Interface]
    Adapter[LegacyPersonaAdapter] ..|> TargetInterface
    Adapter --> Adaptee[LegacyPersonaSdk]

Enter fullscreen mode Exit fullscreen mode

代码实现

// 1. 干净的应用目标契约
public interface KycVerifier {
    KycResult verifyUser(UserIdentity identity);
}

// 领域模型
record UserIdentity(String passportNumber, String countryCode) {}
record KycResult(boolean status, String referenceId) {}

// 2. 不可修改的外部 API / 被适配者
class LegacyPersonaSdk {
    public int executeCheck(String passportNum, String countryIso2) {
        System.out.println("Calling Legacy Persona API...");
        return 200;
    }
}

// 3. 实现目标契约的具体适配器
public class LegacyPersonaAdapter implements KycVerifier {
    private final LegacyPersonaSdk legacySdk;

    public LegacyPersonaAdapter(LegacyPersonaSdk legacySdk) {
        this.legacySdk = legacySdk;
    }

    @Override
    public KycResult verifyUser(UserIdentity identity) {
        // 将领域模型转换为遗留 SDK 参数
        int rawStatusCode = legacySdk.executeCheck(identity.passportNumber(), identity.countryCode());

        // 将遗留响应码转换为干净的领域响应对象
        boolean passed = (rawStatusCode == 200);
        return new KycResult(passed, "PERSONA-TX-" + System.currentTimeMillis());
    }
}

// 4. 干净的业务逻辑（完全与遗留厂商代码解耦）
public class OnboardingService {
    private final KycVerifier kycVerifier;

    // 通过接口注入
    public OnboardingService(KycVerifier kycVerifier) {
        this.kycVerifier = kycVerifier;
    }

    public boolean onboardUser(UserIdentity identity) {
        KycResult result = kycVerifier.verifyUser(identity);
        return result.status();
    }
}

Enter fullscreen mode Exit fullscreen mode

为什么需要它？

• 厂商无关性：防止内部领域契约被外部厂商模型左右。
• 对变更的韧性：更换厂商只需编写新的适配器实现；核心业务代码保持不变。

架构权衡

• 数据映射开销：将内部模型映射为厂商特定参数会增加少量 CPU 与内存开销。
• 抽象泄露：若目标遗留系统缺少关键能力，适配器可能需执行变通或隐藏缺失功能。

何时应避免或拒绝使用

• 直接 1:1 镜像接口：创建仅透传参数而无需修改签名或格式的适配器会引入不必要的样板代码。
• 内部代码所有权：若你同时拥有调用方和接收方源码，应直接重构目标 API，而非包装适配器。

---

4. 观察者模式

核心概念

Observer 模式定义一对多发布-订阅依赖。当核心主题发生状态变更时，它会向已注册的观察者广播事件通知，而无需了解其具体细节或执行机制。

场景：订单结账副作用

在电商应用中下单后，需执行下游动作：发送客户邮件通知并更新仓库库存。

❌ 违背架构：硬编码副作用

public class OrderService {
    private final EmailService emailService = new EmailService();
    private final InventoryService inventoryService = new InventoryService();

    public void placeOrder(String orderId, String customerId, double amount) {
        // 核心业务事务
        System.out.println("Order " + orderId + " saved to DB.");

        // 错误设计：核心服务显式知晓并同步调用下游任务
        emailService.sendConfirmationEmail(customerId, orderId);
        inventoryService.deductStock(orderId);
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ 重构架构：解耦的发布-订阅系统

graph TD
    OrderService[OrderService] --> Publisher[OrderPublisher]
    Publisher --> ListenerInterface[OrderEventListener]
    ListenerInterface <|.. EmailListener[EmailNotificationListener]
    ListenerInterface <|.. InventoryListener[InventoryUpdateListener]

Enter fullscreen mode Exit fullscreen mode

代码实现

// 1. 不可变事件负载
public record OrderPlacedEvent(String orderId, String customerId, double amount) {}

// 2. 观察者（订阅者）接口
public interface OrderEventListener {
    void onOrderPlaced(OrderPlacedEvent event);
}

// 3. 具体观察者（解耦的副作用）
public class EmailNotificationListener implements OrderEventListener {
    @Override
    public void onOrderPlaced(OrderPlacedEvent event) {
        System.out.println("Sending email to customer " + event.customerId() + " for order " + event.orderId());
    }
}

public class InventoryUpdateListener implements OrderEventListener {
    @Override
    public void onOrderPlaced(OrderPlacedEvent event) {
        System.out.println("Deducting inventory stock for order " + event.orderId());
    }
}

// 4. 主题/发布者（管理订阅者并广播事件）
public class OrderPublisher {
    private final List<OrderEventListener> listeners = new ArrayList<>();

    public void registerListener(OrderEventListener listener) {
        listeners.add(listener);
    }

    public void publishOrderPlaced(OrderPlacedEvent event) {
        for (OrderEventListener listener : listeners) {
            try {
                listener.onOrderPlaced(event);
            } catch (Exception e) {
                // 隔离订阅者失败，避免影响其他监听器
                System.err.println("Subscriber failed: " + e.getMessage());
            }
        }
    }
}

// 5. 干净的核心业务逻辑
public class OrderService {
    private final OrderPublisher publisher;

    public OrderService(OrderPublisher publisher) {
        this.publisher = publisher();
    }

    public void placeOrder(String orderId, String customerId, double amount) {
        // 核心业务逻辑
        System.out.println("Order " + orderId + " saved to DB.");

        // 干净的事件广播：OrderService 不直接依赖 Email 或 Inventory 服务
        publisher.publishOrderPlaced(new OrderPlacedEvent(orderId, customerId, amount));
    }
}

Enter fullscreen mode Exit fullscreen mode

为什么需要它？

• 消除组件间的紧耦合。
• 每个监听器可单独构建与测试，单个监听器失败不会影响其他监听器，新监听器加入也不会破坏现有流程。
• 有助于遵循单一职责原则、开闭原则及依赖倒置原则。

架构权衡

• 隐藏的执行链与调试复杂性：由于订阅者是动态注册的，通过日志文件追踪控制流变得困难。你无法再简单地在 IDE 中“转到定义”查看状态变更后发生的所有事情。

何时应避免或拒绝使用

• 若流程仅有一个永久且永不改变的副作用，引入观察者注册表会造成不必要的间接调用。

扩展：从内存观察者到分布式架构

在微服务架构中，内存观察者会演变为分布式事件驱动架构（EDA）。服务不再使用内存注册表，而是向 Apache Kafka、AWS SNS/SQS 或 RabbitMQ 等分布式代理发布消息。

为在不丢失事件的前提下保持系统一致性，生产架构通常与事务性发件箱模式搭配使用：

1. 业务数据与事件记录在同一数据库事务中写入数据库。
2. 独立的转发进程读取发件箱条目并将其发布到消息代理。

graph LR
    subgraph Microservice Context
        Service[Order Service] --> DB[(Database / Outbox Table)]
    end
    DB --> Relay[Debezium / Outbox Publisher]
    Relay --> Broker[Apache Kafka / RabbitMQ]
    Broker --> Listener1[Notification Service]
    Broker --> Listener2[Inventory Service]

Enter fullscreen mode Exit fullscreen mode

---

5. 装饰器模式

核心概念

Decorator 模式允许在运行时动态为对象添加职责，而无需修改其核心代码或引入静态子类爆炸。它用多层包装器包装核心组件，每层添加横切行为。

场景：信用卡处理可选附加组件

信用卡处理服务可通过运行时可选附加组件（如欺诈检查和审计日志）进行增强。

❌ 违背架构：子类排列混乱

为每种可选行为组合创建子类会导致类数量呈指数级增长。

graph TD
    A[PaymentProcessor Base] --> B[FraudCheckingPaymentProcessor]
    A --> C[AuditLoggingPaymentProcessor]
    A --> D[MetricsPaymentProcessor]
    B --> E[Fraud + Logging PaymentProcessor]
    C --> E
    C --> F[Logging + Metrics PaymentProcessor]
    D --> F
    B --> G[Fraud + Metrics PaymentProcessor]
    D --> G
    E --> H[Fraud + Logging + Metrics PaymentProcessor]
    F --> H
    G --> H

Enter fullscreen mode Exit fullscreen mode

public class BasicPaymentProcessor {
    public void processPayment(double amount) {
        System.out.println("Processing credit card payment of $" + amount);
    }
}

// 每种组合都需要子类排列！
public class LoggingPaymentProcessor extends BasicPaymentProcessor { /* ... */ }
public class FraudCheckingPaymentProcessor extends BasicPaymentProcessor { /* ... */ }
public class LoggingAndFraudCheckingPaymentProcessor extends BasicPaymentProcessor { /* ... */ }
// 添加 3 个新特性将导致子类爆炸！

Enter fullscreen mode Exit fullscreen mode

---

✅ 重构架构：动态组合链

graph LR
    Client[Client Code] --> FraudDecorator[FraudCheckDecorator]
    FraudDecorator --> AuditDecorator[AuditLoggingDecorator]
    AuditDecorator --> Core[StandardPaymentProcessor]

Enter fullscreen mode Exit fullscreen mode

代码实现

// 1. 组件接口
public interface PaymentProcessor {
    void processPayment(double amount);
}

// 2. 具体基础组件（核心领域逻辑）
public class StandardPaymentProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        System.out.println("Executing core payment debit of $" + amount);
    }
}

// 3. 抽象装饰器（保持对被包装组件的引用）
public abstract class PaymentProcessorDecorator implements PaymentProcessor {
    protected final PaymentProcessor wrappedProcessor;

    public PaymentProcessorDecorator(PaymentProcessor wrappedProcessor) {
        this.wrappedProcessor = wrappedProcessor;
    }

    @Override
    public void processPayment(double amount) {
        wrappedProcessor.processPayment(amount); // 默认委托
    }
}

// 4. 具体装饰器 A
public class FraudCheckDecorator extends PaymentProcessorDecorator {
    public FraudCheckDecorator(PaymentProcessor wrappedProcessor) {
        super(wrappedProcessor);
    }

    @Override
    public void processPayment(double amount) {
        System.out.println("[FRAUD CHECK] Validating risk score for amount: $" + amount);
        super.processPayment(amount); // 委托给下一层
    }
}

// 具体装饰器 B
public class AuditLoggingDecorator extends PaymentProcessorDecorator {
    public AuditLoggingDecorator(PaymentProcessor wrappedProcessor) {
        super(wrappedProcessor);
    }

    @Override
    public void processPayment(double amount) {
        System.out.println("[AUDIT LOG] Payment initiated at " + System.currentTimeMillis());
        super.processPayment(amount); // 委托给下一层
        System.out.println("[AUDIT LOG] Payment execution finished.");
    }
}

// 5. 使用 / 管道构建
public class PaymentApplication {
    public static void main(String[] args) {
        // 基础处理器
        PaymentProcessor processor = new StandardPaymentProcessor();

        // 在运行时动态组合处理管道：欺诈检查 -> 审计日志 -> 核心支付
        PaymentProcessor securePipeline = new FraudCheckDecorator(
            new AuditLoggingDecorator(processor)
        );

        securePipeline.processPayment(250.00);
    }
}

Enter fullscreen mode Exit fullscreen mode

为什么需要它？

• 防止类爆炸：用动态组合替代静态继承组合。
• 单一职责原则：横切关注点（日志记录、欺诈检查、指标）被分离到各自的包装器类中。

架构权衡

• 身份危机：装饰后的实例与内部被包装组件不共享对象身份（decoratedObject != innerObject）。相等性检查（==）或基于反射的逻辑可能会失效。
• 顺序开销：若装饰器依赖特定执行顺序，嵌套组合可能引入微妙的运行时错误。

何时应避免或拒绝使用

• 严格的顺序依赖：若装饰器 A 必须始终在装饰器 B 之前执行，且乱序执行会破坏系统状态，则包装管道会增加风险。
• 框架拦截器可用：现代企业框架提供面向方面编程（AOP）或中间件/过滤器管道（如 Spring AOP、Express 中间件、gRPC 拦截器），可在不手动实例化对象包装器的情况下干净地处理横切关注点。

---

💡 获取完整 10 页系统设计指南

订阅 The Tech Builder Newsletter 即可立即免费获取完整未删减指南。

订阅者每周将收到：

• 🎯 深度生产事后分析与系统设计权衡分析。
• 🛠️ 面向高级个人贡献者、技术主管及架构师的真实架构手册。
• 🎁 即时福利：订阅后立即获得 完整 6 个月备考追踪器与学习计划 + 10 页系统设计速查表。

👉 获取完整系统设计速查表