根本原因是路径解析基准为当前工作目录而非类路径；IDE运行时工作目录因环境而异，应打印确认；classpath资源须用getResourceAsStream()；读中大文件需BufferedInputStream批量读以提升性能。
FileInputStream 读取文件时为什么总是抛出 FileNotFoundException？
根本原因通常是路径没写对，而不是文件真丢了。Java 的 FileInputStream 默认以当前工作目录（不是类路径、也不是 src 目录）为基准解析相对路径。
- 运行 JAR 包时，
"data.txt"指的是 JAR 所在目录下的data.txt，不是 JAR 包内部的资源 - IDE 运行时，当前工作目录通常是项目根目录，但不同 IDE（IntelliJ / Eclipse）可能有差异，建议用
System.getProperty("user.dir")打印确认 - 若文件在 classpath 下（如
src/main/resources/config.json），别用FileInputStream，改用Class.getResourceAsStream()
BufferedInputStream + FileInputStream 组合还有必要吗？
有必要，尤其读取中大文件（几 MB 以上）时。直接用 FileInputStream.read() 单字节读取，系统调用太频繁，性能极差；而 BufferedInputStream 自动缓存，默认 8192 字节缓冲区，能大幅减少底层 I/O 次数。
- 不要手动包装成
new BufferedInputStream(new FileInputStream(...))后再调用read()单字节——这仍慢，应改用read(byte[])批量读 - JDK 9+ 推荐优先用
Files.readAllBytes(Paths.get(...))读小文件（ - 注意：
BufferedInputStream不改变异常类型，FileNotFoundException和IOException仍需显式捕获或声明
FileInputStream 与 Scanner 混用会出什么问题？
会丢数据，甚至阻塞。因为 Scanner 内部也维护缓冲区，它可能从 FileInputStream 预读若干字节（比如为了判断下一行是否存在），而你后续又用原流的 read()，就会跳过这部分已读未消费的数据。
- 选一个：要么全程用
Scanner（适合按行/按词解析文本），要么全程用FileInputStream+InputStreamReader+BufferedReader（更可控、支持编码指定） -
Scanner默认使用平台默认编码，中文环境易乱码；务必用new Scanner(inputStream, "UTF-8")显式指定 - 关闭流时，只关外层（如
Scanner或BufferedReader），它会自动委托关闭底层FileInputStream
try (FileInputStream fis = new FileInputStream("log.bin");
BufferedInputStream bis = new BufferedInputStream(fis)) {
byte[] buf = new byte[4096];
int len;
while ((len = bis.read(buf)) != -1) {
// 处理 buf[0] 到 buf[len-1]
}
} catch (IOException e) {
// 注意：FileInputStream 构造本身可能抛出 FileNotFoundException
// 它是 IOException 子类，统一 catch 即可
}
真正容易被忽略的是：FileInputStream 的 available() 方法返回值不可靠，不能用来判断是否读完或分配缓冲区大小；它只是“当前可不阻塞读取的估计字节数”，对文件可能返回全部长度，也可能只返回部分，取决于底层实现和 OS。 
