答案是底层原始流（如FileOutputStream）被提前关闭。BufferedOutputStream仅缓冲数据，不管理物理资源；若其包装的原始流在它使用前已被关闭，则后续write或flush均抛出“Stream Closed”异常，即使未显式调用bos.close()。
BufferedOutputStream 在未显式调用 close() 却抛出 “Stream Closed” 异常，通常不是它自己主动关闭的，而是其底层包装的输出流（如 FileOutputStream）已被提前关闭——这是最常见也最容易被忽略的根本原因。
检查底层流是否被提前关闭
BufferedOutputStream 本身不持有物理资源，它只是缓冲层，真正管理文件句柄或网络连接的是它包装的原始流（例如 FileOutputStream、SocketOutputStream）。如果这个原始流在 BufferedOutputStream 还没用完时就被 close 了，后续任何 write 或 flush 操作都会触发 “Stream Closed” 异常。
- 确认是否在构造 BufferedOutputStream 后，又单独对原始流调用了
close() - 检查是否有 try-with-resources 嵌套或重复关闭：比如用 FileOutputStream 创建了 BufferedOutputStream，又在另一个作用域里关了 FileOutputStream
- 留意日志或调试中是否出现多次 close 调用（尤其是同一对象被 close 两次）
注意 flush() 不等于 close()
很多人误以为调用 flush() 就完成了写入并可安全丢弃流，但 flush 只是把缓冲区数据推到底层流，并不释放资源。如果之后还尝试 write 或再次 flush，而底层流已关闭，就会报错。
- BufferedOutputStream 的
flush()会调用底层流的 flush()，但不会 close 底层流 - 若底层流已被关闭，再调 flush() 就会抛 Stream Closed（哪怕你从没调过 close()）
- 务必区分“刷新”和“关闭”：flush 是清空缓冲，close 是释放资源 + 隐式 flush
排查自动资源管理中的陷阱
使用 try-with-resources 时，如果声明了多个流嵌套，关闭顺序和作用域容易出错。
立即学习“Java免费学习笔记（深入）”；
- 正确写法：只声明最外层包装流（如 BufferedOutputStream），它会在 close 时自动关闭底层流
- 错误写法：同时声明 FileOutputStream 和 BufferedOutputStream，导致底层流被提前关闭
- 示例错误：
try (FileOutputStream fos = new FileOutputStream("a.txt"); BufferedOutputStream bos = new BufferedOutputStream(fos)) { bos.write(1); } // fos 和 bos 都在这里 close，但顺序由 JVM 决定，可能 fos 先关应改为只声明 bos
验证流生命周期是否被意外截断
某些框架或工具类（如 Apache Commons IO、Spring 的 ResourceUtils）可能在内部封装并提前关闭流；或者异步任务中流对象被多个线程共享，一个线程 close 后另一线程继续使用。
- 检查是否将 BufferedOutputStream 传递给了其他方法，而该方法内部执行了 close
- 查看是否有类似
IOUtils.closeQuietly()的调用，它可能静默关闭了你还在用的流 - 在关键位置加日志或断点，确认流对象的 close 方法被调用的确切时机和调用栈
