工作七年总结：这 7 种设计模式，解决 99% 的 Java 开发场景
（2025 年真实项目版，背下来直接升架构师）
我把过去 7 年踩过的坑、背过的锅、扛过的锅，全都浓缩成这 7 个模式。
99% 的业务系统（电商、金融、SaaS、中台、工具平台）只要把这 7 个玩熟，代码质量、扩展性、可维护性直接吊打 95% 的同行。
| 排名 | 模式名称 | 真实解决场景（2025 年最常见） | 一句话总结（背下来） | 我见过最惨的反例 |
|---|---|---|---|---|
| 1 | 模板方法（Template Method） | 所有支付、订单、下单、发券、发消息、发邮件、报表导出、定时任务的流程框架 | “流程骨架写死，子类只填坑（prepare → check → execute → callback） | 2000 行 Service 里全是 if-else 判断渠道 |
| 2 | 策略模式 + 工厂（Strategy + Factory） | 支付渠道、风控策略、优惠券计算、推送渠道、物流策略、消息路由 | 一个接口 N 个实现，工厂根据类型/配置动态注入，永远不写 switch | 500 行的 if (channel.equals(“alipay”)) |
| 3 | 责任链（Chain of Responsibility） | 风控校验、下单前置检查、订单状态流转、权限校验、参数校验 | 把一堆 if 判断拆成一个个 Handler，顺序可配、可插拔 | 800 行 validate() 方法，改一个全抖 |
| 4 | 装饰器（Decorator） | 缓存装饰、日志装饰、限流装饰、监控装饰、事务装饰、权限装饰 | 不改原类，动态给方法加“外挂”（AOP 本质就是装饰器） | 每个方法手动写 try-catch + log + cache |
| 5 | 观察者（Observer） | 订单状态变更通知、库存回滚、积分发放、消息推送、事件总线 | 一件事发生 N 个地方要知道，用事件 + 监听，比硬编码回调优雅 100 倍 | 订单状态改了 18 个地方要改，漏一个就出bug |
| 6 | 建造者（Builder） | 复杂对象构造：订单创建、入参组装、报表查询条件、MQ 消息体、Excel 导出参数 | 必填 + 可选参数太多时，用 Builder 替代 10 个构造函数 | 15 个参数的构造函数，参数顺序一乱全崩 |
| 7 | 适配器（Adapter） | 对接第三方：支付、短信、推送、OSS、开放平台、老系统接口 | 把别人的奇葩接口包装成我们统一的样子，业务代码永远不感知不到第三方变化 | 业务代码里全是支付宝、微信的 SDK 原始返回 |
2025 年真实项目落地写法（直接抄）
// 1. 模板方法 + 策略 + 责任链 + 观察者 完美结合（我现在所有核心流程都这么写）
public abstract class AbstractPayTemplate {
// 模板方法（骨架固定）
public final PayResult pay(PayRequest request) {
prepare(request);
List<Validator> chain = validatorFactory.buildChain(request.getChannel());
chain.forEach(v -> v.validate(request)); // 责任链
PayStrategy strategy = strategyFactory.get(request.getChannel()); // 策略+工厂
PayResult result = strategy.doPay(request);
eventBus.post(new PaySuccessEvent(result)); // 观察者
return result;
}
protected abstract void prepare(PayRequest request);
}
// 2. 装饰器 + AOP（Spring 已经帮你写好了）
@Cacheable、@Transactional、@Idempotent、@RateLimiter 本质全是装饰器我见过最惨的 3 个反面案例（年薪 50w+ 的人写的）
- 3000 行 OrderService，里面 47 个 if (channel.equals(…))
- 下单流程 18 次数据库查询，全在一个方法里，改状态要改 9 个地方
- 第三方支付回调直接写在 Controller 里，换微信支付要改 300行
终极结论（2025 年面试/升职必背）
| 场景 | 必须用的模式 | 一句话口诀 |
|---|---|---|
| 流程固定、步骤可扩展 | 模板方法 | 骨架写死，子类填坑 |
| 同一类算法多种实现 | 策略 + 工厂 | if-else 死，策略活 |
| 一堆校验/过滤 | 责任链 | 单个职责，自由组合 |
| 给方法加功能不改原代码 | 装饰器（AOP） | 横切关注，优雅外挂 |
| 一对多事件通知 | 观察者（事件总线） | 解耦神器，改一不改百 |
| 参数超多 | 建造者 | 15个参数，Builder 走起 |
| 对接第三方奇葩接口 | 适配器 | 脏活累活我干，业务只看统一 |
这 7 个模式玩熟了，
你写出来的代码，架构师看了会沉默，leader 看了会流泪，面试官看了会鼓掌。
你现在项目里，最常用的是哪几个？
敢不敢把你最长的 Service 贴出来，我现场用这 7 个模式给你重构到 200 行以内？来！
