BufferedInputStream 必须套在 FileInputStream 外面，因装饰器模式要求被装饰对象（FileInputStream）必须先存在；反之则编译失败，因 FileInputStream 构造函数不接受 BufferedInputStream 参数。
为什么 BufferedInputStream 必须套在 FileInputStream 外面，不能反过来？
因为装饰器模式要求被装饰对象（如 FileInputStream）必须先存在，装饰器（如 BufferedInputStream）只是增强它的行为，而不是替代它。反过来套——比如把 FileInputStream 构造在 BufferedInputStream 之后——会直接编译失败：构造函数根本不接受一个 BufferedInputStream 作为参数。
常见错误现象：BufferedInputStream bis = new BufferedInputStream(new BufferedInputStream(fis)) 看似“更缓冲”，实则无意义，还多一层对象开销；更糟的是写成 new FileInputStream(new BufferedInputStream(...))，编译报错：constructor FileInputStream(File) not found。
-
FileInputStream是最底层的字节源，只管从文件读字节，不缓存、不跳过、不标记 -
BufferedInputStream的构造函数签名是BufferedInputStream(InputStream in)，它只认InputStream子类，且期望这个子类已经能“真正读数据” - 顺序错了，就破坏了装饰链的起点——没有真实数据源，所有上层装饰都成空中楼阁
FilterInputStream 和 FilterOutputStream 是装饰器的骨架，但别直接用它们
这两个是抽象类，Java IO 里大部分“可叠加功能”的类（比如 BufferedInputStream、DataInputStream、CheckedInputStream）都继承自 FilterInputStream。它提供了默认委托逻辑：read()、skip()、available() 都直接转发给内部的 in 字段。
但你几乎不该自己 new 一个 FilterInputStream 实例——它没实现任何具体功能，也没公开 in 字段，无法定制。真要写自定义装饰器，应该继承它并重写需要增强的方法；否则，直接用现成子类更安全。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 误用示例：
new FilterInputStream(someStream)编译通过但毫无作用，运行时调read()就是原样转发，没加任何逻辑 - 性能影响：每多一层装饰器，就多一次方法调用+对象引用，高频小读取时，
BufferedInputStream能显著降低系统调用次数；但叠太多层（如 Buffer → Data → Cipher）会增加栈深度和对象分配压力 - JDK 9+ 中部分装饰器（如
Base64InputStream）内部做了 buffer 复用优化，但老版本的FilterInputStream子类基本都是简单转发
关闭流时只关最外层，但得确保它是 Closeable
装饰器模式下，所有标准 IO 装饰器（BufferedInputStream、DataInputStream 等）都实现了 Closeable，且 close() 方法会递归关闭内部的被装饰流。所以你只需要调最外层装饰器的 close()，不用逐层关。
容易踩的坑是：有人为了“保险”把每个中间流都 close() 一遍，结果第二次 close() 可能抛 IOException（尤其在某些 JDK 实现或自定义装饰器里），或者引发 NullPointerException（因为内层流已被置为 null）。
- 正确做法：
try (DataInputStream dis = new DataInputStream(new BufferedInputStream(new FileInputStream("a.txt")))) { ... }—— try-with-resources 自动关最外层，内层跟着关 - 如果手动关，只写
dis.close()，别再写bis.close()或fis.close() - 注意：某些第三方装饰器（比如 Apache Commons 的
CountingInputStream）可能没正确实现递归关闭，这种要查文档或源码确认
为什么 PushbackInputStream 不能和 BufferedInputStream 随便混用？
两者都用内部 buffer，但语义冲突：PushbackInputStream 的 buffer 用于“把刚读的字节退回去”，是逻辑回溯；BufferedInputStream 的 buffer 是预读优化，用户不可见。如果套在一起（比如 new PushbackInputStream(new BufferedInputStream(fis))），unread() 推入的字节会被 BufferedInputStream 的 fill() 逻辑干扰——可能被覆盖、延迟可见，甚至触发重复读。
典型错误现象：调 unread(65) 后紧接着 read()，结果读到的不是 65，而是 buffer 里原来的内容，或干脆阻塞。
- 使用场景明确：需要语法解析、词法预读时用
PushbackInputStream；追求吞吐量时用BufferedInputStream；二者一般不共存 - 如果非得有缓冲+回退，优先选
PushbackInputStream自带的buf（它本身就有缓冲能力），或者用ByteArrayInputStream做中间暂存 - 参数差异：
PushbackInputStream构造时可指定pushbackSize，而BufferedInputStream的size默认 8192；大小不匹配会放大语义混乱
