FileInputStream 的 read() 方法返回 -1 表示已读到文件末尾，属正常行为；需用 while((b=fis.read())!=-1) 正确判断，不可误判为错误。

FileInputStream 读取文件时为什么返回 -1？

因为已经读到文件末尾，read() 方法返回 -1 是正常行为，不是错误。很多人误以为是路径错或权限问题，其实只是循环没控制好。

• 必须用 while ((b = fis.read()) != -1) 判断，不能写成 != 0 或漏掉括号
• 如果文件为空，第一次 read() 就返回 -1，循环体一次都不会执行
• read() 每次只读 1 字节，返回 int（0–255），不是 byte；直接强转可能丢符号位，但这里不影响判断

想一次读完所有字节，该用 read(byte[]) 还是 readAllBytes()？

Java 9+ 推荐用 readAllBytes()，它内部已处理循环读取和扩容，代码简洁且不易出错；老版本只能靠 read(byte[]) 手动循环。

• fis.readAllBytes() 自动分配合适大小的 byte[]，无需预估文件长度
• 用 read(byte[]) 时，返回值是「本次实际读到的字节数」，可能小于数组长度，必须用返回值截取有效数据
• 常见错误：把整个 byte[] 当作内容输出，导致末尾出现乱码（其实是未填充的 0）
• 大文件慎用——readAllBytes() 会一次性加载全部内容进内存

FileInputStream 抛出 FileNotFoundException 怎么快速定位原因？

不是“文件不存在”这么简单，要逐项检查路径解析、工作目录、权限三要素。

• 传入的是相对路径时，JVM 当前工作目录（System.getProperty("user.dir")）决定根位置，不是类路径也不是 IDE 运行目录
• 路径中含中文或空格，未做 URL 编码或未用 File.toURI() 转换，容易被截断
• Linux/macOS 下注意大小写敏感；Windows 上虽然不敏感，但某些安全策略会拦截访问
• IDE 运行时，确认「Working directory」配置是否覆盖了默认路径

关闭流时 try-with-resources 为什么比 finally 更可靠？

因为 close() 本身可能抛异常，手动写 finally 容易掩盖原始异常，而 try-with-resources 保证资源释放且不吞异常。

• 必须把 FileInputStream 声明在 try 括号内，如 try (FileInputStream fis = new FileInputStream(path)) { ... }
• 不要在 try 块里再调用 fis.close()，会导致 IllegalStateException
• 如果同时操作多个流（比如读 + 写），可以写在同一 try 后括号里，用分号隔开
• 即使构造函数抛出 FileNotFoundException，try-with-resources 仍能确保后续声明的资源不泄漏

真正麻烦的不是读数据，而是路径怎么算对、异常怎么传出来、大文件要不要分块——这些细节不写进日志，线上就只能靠猜。