InputStream.read() 返回 -1 表示流已到达末尾，而非错误；仅底层异常时抛 IOException；循环读取须用 while((b=in.read())!=-1) 判断，read(byte[]) 返回实际字节数，可能为0或-1。
InputStream.read() 返回 -1 表示什么
InputStream.read() 返回 -1 不代表出错，而是明确表示“流已到达末尾”，即没有更多字节可读。很多初学者误判为异常，继而抛出错误或中断正常逻辑。
- 仅当底层连接异常（如 socket 关闭、文件被删除）时才会抛
IOException，此时不会返回-1 - 循环读取必须用
while ((b = in.read()) != -1)判断，不能写成!= 0或忽略返回值 - 使用
read(byte[] b)重载时，返回值是“实际读到的字节数”，也可能是 0（比如非阻塞流暂无数据），只有读不到任何字节且流已关闭才返回-1
OutputStream.write() 写入后数据不一定立刻落盘
调用 write() 只是把字节拷贝进内存缓冲区，操作系统和 JVM 并不保证立即写入目标（文件、socket 等）。这会导致看似“写完了”但文件为空、网络端收不到数据等问题。
- 必须显式调用
flush()强制清空缓冲区，尤其在写完关键数据后（如协议头、心跳包） - 关闭流（
close()）会隐式触发flush()，但不能依赖它——如果中间发生异常提前退出，close()可能没执行 - 对文件输出，若需强一致性（如日志落盘），建议搭配
FileOutputStream的getChannel().force(true)
为什么 BufferedInputStream/BufferedOutputStream 几乎总是该用的
直接对 FileInputStream 或 SocketInputStream 调用单字节 read()，性能极差：每次调用都可能触发一次系统调用或网络往返。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
BufferedInputStream默认 8192 字节缓冲，把多次小读合并为一次大读；BufferedOutputStream同理聚合写操作 - 即使源流本身有缓冲（如某些 HTTP 客户端），应用层再套一层仍有效——JVM 层缓冲和 OS 层缓冲作用域不同
- 注意：缓冲流的
mark()/reset()依赖内部数组，超出readlimit会失效；且reset()不能跨缓冲区边界
InputStream 和 OutputStream 不能直接互转，但可以安全桥接
没有内置方法把 InputStream “变成” OutputStream，反之亦然。强行用 PipedInputStream/PipedOutputStream 易死锁，且要求严格线程配对。
立即学习“Java免费学习笔记（深入）”；
- 常见需求如“把 HTTP 响应体转成字符串”，应使用
InputStream+InputStreamReader+BufferedReader，而非试图构造输出流 - 需要双向流转（如 mock 测试），优先用
ByteArrayInputStream/ByteArrayOutputStream中转，它们线程安全、无阻塞、不依赖外部资源 - Java 9+ 可用
InputStream.transferTo(OutputStream)避免手动循环，底层走零拷贝优化（如FileChannel.transferTo），但目标OutputStream必须支持write(byte[], int, int)
BufferedInputStream 的缓冲数组是私有字段，无法复用；频繁创建小缓冲流（如每个请求 new 一个 128 字节 buffer）反而增加 GC 压力。生产环境建议复用缓冲数组或统一配置合理大小（如 4KB–64KB）。 
