装饰者模式用组合代替继承，通过实现同一接口并持有被装饰对象引用来动态增强行为；典型案例如JDK中InputStream系列装饰器；常见错误包括错误继承导致ClassCastException、漏写equals/hashCode、空指针、资源未复用等。
装饰者模式不是“给类加个注解”，而是用组合代替继承，在运行时动态套一层新行为。
为什么不能直接继承？
继承写死在编译期，一个子类只能固定扩展一种能力；而装饰者允许你像叠纸杯一样，new LoggingDecorator(new AuthDecorator(new ServiceImpl()))，顺序、数量、组合方式全由调用方决定。
常见错误现象：ClassCastException —— 有人试图让装饰器继承被装饰类，又把它强转回原类型，结果父类引用指向子类实例，但装饰器根本没重写所有方法，一调就崩。
- 装饰器必须和被装饰类实现同一接口（比如
Service），而不是继承它 - 装饰器内部持有一个该接口的引用（通常是构造函数传入），所有方法默认委托给它
- 只在需要增强的地方重写，其余保持透传
InputStream 是最典型的装饰者现实案例
JDK 里的 BufferedInputStream、DataInputStream、GZIPInputStream 全是装饰器：它们都接收一个 InputStream，自己也返回 InputStream，调用方完全感知不到底层是谁。
立即学习“Java免费学习笔记（深入）”；
使用场景：读文件时既要缓冲、又要解压、还要按行解析——不用改 FileInputStream 一行代码，直接套三层：
new BufferedReader(
new InputStreamReader(
new GZIPInputStream(
new FileInputStream("data.gz"))))
注意参数差异：GZIPInputStream 构造函数只接受 InputStream，不接受 File 或路径；BufferedReader 接受的是 Reader，所以中间必须用 InputStreamReader 转码——漏掉任何一层，编译直接报错。
自己写装饰器时最容易漏掉的三件事
很多人写了构造函数、重写了几个方法，就以为完事了，结果上线后出诡异 bug。
- 忘记重写
equals()和hashCode()—— 如果装饰器参与缓存或集合操作，两个功能相同但包装层级不同的对象会判为不等 - 装饰器里调用被装饰对象的方法时，没做空判断，
delegate.doSomething()中delegate是 null 就直接NullPointerException - 性能陷阱：有些装饰器会在每次调用时新建资源（比如每次
log()都开一个FileWriter），应该把资源提到构造期初始化并复用
真正难的不是写出来，是想清楚哪一层该做什么、谁负责释放资源、异常怎么透传——这些不会体现在 UML 图上，但线上挂了第一个找的就是这儿。
