贵萌兄搞后端这几年，我发现一个特别有意思的现象：凡是在继承这条路上走得太顺的人，迟早会在某一个需求版本里翻车。比如你设计了一个通知类，起初只要发站内信；产品经理说还要支持发短信，于是你加了个子类；下周说还要支持发微信，又加了一个子类。等到某天要求“短信+微信”同时发的时候，你突然发现自己站在一个选择题面前：是给每种组合都建一个子类，还是干脆重构。
而装饰者模式，就是为这类“不断叠加功能、又不希望爆类”的场景准备的。这篇文章不打算搞学术演绎，我会先讲清楚它到底解决了什么难题，再带你把整个模式手写一遍，接着拆几个知名源码里真实的使用案例，最后把容易踩的坑和排查思路整理成清单。无论你是在准备面试，还是手头正好有个“功能叠加型”需求，都值得往下看。
1. “加功能”为什么这么难：装饰者模式要解决的根本问题
1.1 继承扩展功能的三个坑
先回到最直觉的写法：用继承给一个类加功能。
假设有一个Notifier负责发送通知，最初只有站内信功能。产品说要加短信，你新建一个SmsNotifier extends Notifier；说要加微信，再建一个WechatNotifier extends Notifier。目前看起来挺合理，每个子类只做一件事。
问题出在组合需求出现那天。用户可能想收到“短信+微信”，也可能想收到“邮件+短信+微信”。如果继续靠继承，你要创建的类数量是按指数级增长的：3种通知手段，会催生8种组合类；5种通知手段，就是32种组合类。你当然可以辩解“很多组合用不上”，但设计代码的时候，没人能保证哪个组合一定不会出现。
更麻烦的是，继承在语义上是静态的。某个类一旦被extends，它在编译期就绑定了固定的增强方式。想动态决定“今天只发微信，明天微信+短信”，用继承改起来非常痛苦，一不小心就把父子关系搅成一锅粥。这也是很多人吐槽“继承导致类爆炸”的根本原因：不是继承本身罪大恶极，而是用静态手段去解决动态叠加问题，注定会别扭。
1.2 组合优于继承：装饰者模式的核心思想
装饰者模式给出的解法很朴素：不要用子类去穷举组合，而是把一个对象装进另一个对象里，让每个包装层负责一部分增强功能。调用的时候，从外往里逐层传递，每一层都可以在转交之前或之后做自己的事情。
拿刚才的通知需求来说，核心组件是BaseNotifier，它只负责站内信。短信增强、微信增强、邮件增强各自做成独立的包装类。要发“短信+微信”时，就把微信包装在短信里面，再把短信包装在核心通知外面。整条链像套娃一样，最小原型永远是那个BaseNotifier，外面套几层完全由使用者说了算。
这本质上就是“组合优于继承”的实践。一个类不再通过继承固定拓展方向，而是通过持有另一份能力，在运行时动态灵活拼接。这样做的好处有两层：一是组合数量从指数级降回线性级，每加一种新通知方式，只需要新增一个装饰类；二是代码的职责边界更清晰，每个装饰类只关心自己的增强逻辑，不需要知道整条链上还有哪些兄弟。
1.3 一句话定义与适用场景
把话说明白：装饰者模式就是在不修改原有类代码的前提下，通过一层层包装对象，动态地给对象增加新职责。
适合用的场景我列一下：
- 功能需要按不同组合方式叠加，且组合种类无法在设计期穷尽；
- 希望保持接口统一，让调用方无感知地使用被增强后的对象；
- 某个核心对象很稳定，但增强逻辑变化频繁，不想污染核心类。
不适合的场景也有：
- 对象结构本身复杂，内部状态需要大量定制，包装层很难做到透明转发；
- 对极端性能有硬要求的场景，多层包装调用会带来额外栈深和转发开销；
- 增强逻辑高度依赖对象内部私有状态的时候，装饰者模式会显得很费劲，不如直接在类里扩展实现。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 手写一个装饰者模式：从组件到装饰者的完整落地
2.1 四个角色先认清楚
模式里的角色，比很多人记忆中的“抽象类+实现类”要多一层。先看这张对应关系表，后面代码全部按这个来写：
| 角色 | 在模式中的职责 | 对应到通知案例 |
|---|---|---|
| Component（抽象组件） | 定义统一的业务接口，让装饰者和被装饰者可以互相替换 | Notifier接口 |
| ConcreteComponent（具体组件） | 核心功能实现，是被装饰的原始对象 | BaseNotifier |
| Decorator（抽象装饰者） | 持有Component引用，负责转发调用，是所有装饰器的基类 | NotifierDecorator |
| ConcreteDecorator（具体装饰者） | 在转发调用的基础上增加增强逻辑 | SmsDecorator、WechatDecorator |
很多初学者会跳过抽象装饰者这一步，直接把增强类实现Component接口。不是不行，但每个增强类都要自己写“持有对象+构造器+转发方法”，代码重复严重。抽象装饰者存在的意义，就是把这套转发模板收敛到一处，具体装饰者只需要关心自己新增的那段逻辑。
2.2 用消息推送写一个最小可运行版本
直接看代码，这套实现是我在项目里用过的简化版，足够说明模式的核心骨架。
java复制// Component：抽象组件
public interface Notifier {
void send(String message);
}
java复制// ConcreteComponent：核心组件，只做站内信
public class BaseNotifier implements Notifier {
@Override
public void send(String message) {
System.out.println("[站内信] " + message);
}
}
java复制// Decorator：抽象装饰者，持有Component引用并转发调用
public abstract class NotifierDecorator implements Notifier {
protected final Notifier wrapper;
public NotifierDecorator(Notifier wrapper) {
this.wrapper = wrapper;
}
@Override
public void send(String message) {
wrapper.send(message);
}
}
java复制// Concret