Java用24年改1个Bug：流式I/O的魔幻进化史

1996年，Java 1.0带着File类亮相时，开发者以为能愉快读写文件了。结果这玩意儿只能创建删除、查查元数据，文件内容？碰都碰不了。就像给你一把钥匙，能开门看门牌号，但进不了屋。

第一章：远古时代，Java"认识"文件却读不了

早期的File类是个半成品。它能告诉你是文件还是目录，能改名能删除，但打开文件看里面写了什么？没门。操作系统把文件捂得严实，Java站在门外干瞪眼。

当时的 workaround 是让开发者自己调本地代码，或者干脆用标准输入输出凑合。System.in和System.out成了救命稻草——至少键盘和屏幕的数据能流动起来。但这显然不够，文件才是数据的老巢。

第二章：流诞生，"一切皆流"的哲学来了

Java团队换了个思路：别管数据来源是文件、网络还是键盘，统一抽象成"流"。字节流就是字节在流动，字符流就是字符在排队，听着玄乎，本质是屏蔽底层差异。

于是InputStream和OutputStream登场。读数据？从InputStream里"抽"。写数据？往OutputStream里"灌"。这套模型够优雅，但问题来了——这俩是抽象类，自己干不了活。

它们不会跟操作系统要文件句柄，也不会跟键盘驱动打交道。就像设计了一辆概念车的底盘，没发动机，轮子也得你自己装。

第三章：实现类补位，流终于落地

真正的突破是具体实现类。FileInputStream和FileOutputStream把抽象流和操作系统文件挂上了钩，BufferedInputStream加了缓冲减少系统调用次数。NIO后来的FileChannel甚至能内存映射，大文件读写直接从内核空间抄近道。

这套演进持续了二十多年。java.nio.file.Files在Java 7里出现时，一行Files.readAllLines()就能搞定当年要写半页代码的事。但底层还是那个流模型——数据在流动，只是管道越铺越顺。

现在回头看，File类还在，但已经成了"路径对象"的配角。流式I/O从笨拙的抽象，变成了Java最耐用的基础设施之一。你最近一次用InputStream是什么时候——是不得已兼容老代码，还是真觉得它比Files顺手？