FilterInputStream虽体现装饰器模式，但存在四大缺陷：一是继承强制暴露底层流、破坏封装；二是装饰能力硬编码、缺乏运行时灵活性；三是与适配器模式职责混淆；四是不适应现代函数式IO范式，已被NIO及新API取代。
FilterInputStream 体现装饰器模式，但存在明显设计缺陷
FilterInputStream 是 Java I/O 中装饰器模式的典型实现，它通过持有一个 InputStream 引用，在不改变原始接口的前提下增强功能。但这个设计在实际使用和演进中暴露出几个关键缺陷，常被用于考察对设计模式本质和 JDK 演化逻辑的理解。
缺陷一：继承关系强制暴露底层流，破坏封装性
FilterInputStream 是 public class FilterInputStream extends InputStream，子类（如 BufferedInputStream、DataInputStream）必须继承它。这导致两个问题：
- 所有子类都继承了 InputStream 的全部抽象方法，哪怕只用其中几个，也必须提供空实现或透传，违反最小接口原则
- 子类直接访问 protected volatile InputStream in 字段，外部可通过反射或继承链绕过装饰逻辑，强行替换 or nullify 底层流，造成行为不可控
- 无法限制“装饰”动作的组合顺序——比如 DataInputStream 必须包装在 BufferedInputStream 之外才安全读取基本类型，但编译期无法阻止反向包装
缺陷二：装饰能力被硬编码进继承树，缺乏运行时灵活性
装饰器模式本应支持任意组合，但 FilterInputStream 体系是静态继承结构：
- 每个功能（缓冲、数据解析、校验等）都对应一个固定子类，不能动态添加/移除行为
- 没有统一的装饰器注册机制或策略接口，新增功能需新增类并修改继承关系，扩展成本高
- 无法像现代函数式方式那样链式调用：new BufferedInputStream(new DataInputStream(in)) 是构造式写法，而非 fluent API
缺陷三：与适配器模式边界模糊，职责不清晰
FilterInputStream 名义上是装饰器，但部分子类（如 PushbackInputStream）已偏离“增强已有功能”的初衷，转向“改变使用方式”：
立即学习“Java免费学习笔记（深入）”；
- PushbackInputStream 提供 unread()，本质是为解析器提供回退能力——这不是对 read() 的增强，而是引入新语义，更接近适配器对协议的转换
- InputStreamReader 虽属字符流体系，但其角色实为字节→字符的适配，却被归入同一包装逻辑层级，混淆了“功能增强”与“接口转换”的设计意图
- 这种混用让开发者难以判断：该用装饰器还是适配器？JDK 自身也没有通过类型系统做区分
缺陷四：无法适配现代编程范式，已被 NIO 和函数式 IO 取代
这些缺陷不是偶然，而是面向对象早期封装思想的局限反映：
- FilterInputStream 依赖继承 + 组合，与组合优先原则冲突；现代实践倾向接口+组合+Builder 或函数式构造（如 Files.newBufferedReader）
- Java 7 的 Paths/Files、Java 8 的 Stream API、以及第三方库（Apache Commons IO、Google Guava）都绕开了 FilterInputStream 的继承链，用更轻量、不可变、函数式的方式组织 IO 行为
- 从 JDK 9 开始，许多 FilterInputStream 子类的构造方法被标记为 @Deprecated for removal（如某些重载），暗示其设计已不被推荐
