BufferedInputStream必须套在已初始化且未关闭的FileInputStream上，正确写法是用try-with-resources管理生命周期，如：try(FileInputStream fis = new FileInputStream("data.bin"); BufferedInputStream bis = new BufferedInputStream(fis)) { ... }。
BufferedInputStream 怎么套在 FileInputStream 上才不报错
必须确保被装饰对象（如 FileInputStream）在构造 BufferedInputStream 时已正确初始化，且未提前关闭。常见错误是传入 null 或已 close 的流，导致 NullPointerException 或 IOException: Stream closed。
正确写法用 try-with-resources 自动管理生命周期：
try (FileInputStream fis = new FileInputStream("data.bin");
BufferedInputStream bis = new BufferedInputStream(fis)) {
int b;
while ((b = bis.read()) != -1) {
System.out.write(b);
}
}
-
BufferedInputStream构造器不检查底层流是否可读，只做包装，出错往往在第一次read()时暴露 - 不能把同一个
FileInputStream实例重复传给多个装饰器（如再套一层DataInputStream），除非你明确控制读取顺序和位置 - 缓冲区默认大小是 8192 字节，若处理小文件或低延迟场景，可显式传入更小值：
new BufferedInputStream(fis, 1024)
ZipInputStream 和 BufferedInputStream 谁该包在里层
缓冲必须在解压缩之前生效，否则 ZipInputStream 每次读一个字节都要触发系统调用，性能极差。所以 BufferedInputStream 必须作为最内层装饰器，包裹原始字节源；ZipInputStream 包在外层。
错误顺序（性能灾难）：
ZipInputStream zis = new ZipInputStream(new FileInputStream("a.zip")); // ❌ 没缓冲
正确顺序：
try (FileInputStream fis = new FileInputStream("a.zip");
BufferedInputStream bis = new BufferedInputStream(fis);
ZipInputStream zis = new ZipInputStream(bis)) { ... }
-
ZipInputStream依赖连续、批量的字节输入来识别 ZIP 格式头，底层流若无缓冲，会反复 read(1)，破坏数据节奏 - 同理，
GZIPInputStream、InflaterInputStream都要求前置缓冲 - 如果源是网络流（如
HttpURLConnection.getInputStream()），更需加缓冲，否则 zip 解压可能卡死或抛EOFException
为什么不能直接继承 FileInputStream 来加缓冲功能
Java IO 类体系中，FileInputStream 是 final 类，无法继承；即使能继承，也会立刻撞上“功能爆炸”问题：你要同时支持缓冲、字符编码、数据类型读取（int/long）、base64 编码、校验和……每加一项就得新建一个子类，组合爆炸。
- 继承是静态的：编译期就确定行为，无法运行时切换（比如同一份代码，有时要缓冲+gzip，有时只要缓冲）
- 装饰器通过组合复用：一个
BufferedInputStream可以装饰任意InputStream子类，包括ByteArrayInputStream、SocketInputStream、甚至自定义流 - 所有装饰器（
BufferedInputStream、DataInputStream、CheckedInputStream）都继承自FilterInputStream，共享统一的委托机制：所有方法默认调in.read()，子类只重写需要增强的部分
OutputStream 装饰链里 flush() 该谁调
只有最外层装饰器（如 BufferedOutputStream 或 ZipOutputStream）的 flush() 才真正触达底层设备。内层流的 flush() 被装饰器拦截并转发，但不一定立即下刷——比如 BufferedOutputStream 的 flush() 会先把缓冲区内容写给 out，再调 out.flush()。
- 手动调
BufferedOutputStream.flush()是必要的，否则缓冲区内容可能滞留；而调FileOutputStream.flush()通常多余（它只是把 JVM 缓冲刷到 OS 缓冲） -
ZipOutputStream的flush()不保证 ZIP 条目写完，必须调closeEntry()或close()才完成条目封包 - 若链中含
PrintStream，它的flush()行为受autoFlush参数控制，和缓冲装饰器的 flush 逻辑不耦合
装饰器模式在 IO 中不是语法糖，它是对“职责分离”和“运行时组合”的刚性需求——缓冲、压缩、编码、校验这些关注点必须能任意叠加，又不能污染原始流的语义。最容易被忽略的是：所有装饰器的构造顺序决定了数据流向，一旦套反（比如把 InputStreamReader 放在 BufferedInputStream 外层），字符解码就会因字节边界错乱而出现乱码或 MalformedInputException。
