InputStream 和 OutputStream 是抽象字节流契约，不可实例化；其子类如 FileInputStream、ByteArrayInputStream 等实现具体数据源读写；BufferedInputStream 通过缓冲减少系统调用提升性能，但需避免冗余包装；资源必须用 try-with-resources 确保关闭；字符流须经 InputStreamReader 指定编码桥接，禁用默认编码。
Java 的 InputStream 和 OutputStream 不是“用来读写文件的工具”，而是抽象的数据管道契约——只要符合字节流协议，就能接入网络、内存、压缩、加密等任意数据源或目的地。
为什么不能直接 new InputStream()？
因为 InputStream 是抽象类，它只定义了 read()、available()、close() 等行为规范，不关心数据从哪来。真正干活的是它的子类：
-
FileInputStream：从磁盘文件读字节 -
ByteArrayInputStream：从内存字节数组读 -
Socket.getInputStream()：从 TCP 连接读入站数据 -
GZIPInputStream：套在另一个InputStream外面，自动解压
你写 new InputStream() 会编译报错：Cannot instantiate the type InputStream。
BufferedInputStream 为什么不是必须加，但几乎总要加？
原始 FileInputStream.read() 每次调用都触发一次系统调用（syscall），频繁读单字节性能极差。而 BufferedInputStream 在内存里维护一个默认 8192 字节的缓冲区，批量读取、按需吐出，把 N 次 syscall 降为约 N/8192 次。
但注意这些细节：
- 缓冲区大小可调：
new BufferedInputStream(in, 64 * 1024) - 如果上游已是高效流（如
ByteArrayInputStream），加缓冲层反而多一层方法调用开销 - 调用
mark()/reset()时，缓冲区会记录位置；若未markSupported()就调用reset()，抛IOException
close() 忘关会怎样？
后果取决于底层资源类型：
- 文件句柄不释放 → 达到系统限制后，后续
new FileInputStream()报java.io.IOException: Too many open files - Socket 流不关 → 连接保持 ESTABLISHED 状态，服务端无法回收连接，可能触发连接池耗尽
- 内存泄漏风险小（JVM 有 finalize，但不可靠）
正确做法永远用 try-with-resources：
try (FileInputStream fis = new FileInputStream("data.bin");
BufferedInputStream bis = new BufferedInputStream(fis)) {
int b;
while ((b = bis.read()) != -1) {
// process
}
} // 自动调用 close()，即使中间抛异常字符流（Reader/Writer）和字节流混用的坑
InputStream 处理 raw bytes，Reader 处理 decoded chars。强行把 FileInputStream 当成文本读，等于跳过编码解码步骤，必然乱码。
典型错误写法：
InputStream is = new FileInputStream("utf8.txt");
int b;
while ((b = is.read()) != -1) {
System.out.print((char) b); // 错！没指定编码，且 UTF-8 多字节字符会被拆开解释正确方式是用 InputStreamReader 桥接，并显式传编码：
try (InputStream is = new FileInputStream("utf8.txt");
InputStreamReader isr = new InputStreamReader(is, StandardCharsets.UTF_8);
BufferedReader br = new BufferedReader(isr)) {
String line;
while ((line = br.readLine()) != null) {
// 正确按 UTF-8 解码后的字符串
}
}别依赖平台默认编码（Charset.defaultCharset()），它在 Windows 和 Linux 上可能不同，部署即翻车。
