java.io.File APIobsolete，表示已弃用（您应该停止使用它），但是，考虑到它是核心API，“deprecated”作为一个专门用于核心的术语意味着“不久的某个时候，无论如何，它都不会工作”，而java.io.File就不是这样了--它10年后还能用。但你还是不应该使用它。它的设计存在一些根本性的问题，这意味着它是一个有缺陷的API，它不会被使用。t（不能）固定。
它的许多缺陷之一是，它在向您传达错误的方式上不像Java。奇怪的是，大多数File API本身不会在出错时抛出异常。相反，它返回不稳定的东西。
例如，如果在空目录上运行file.list()，它将返回一个空数组，但如果它无法完成此任务，则返回null（例如，目录不存在，或者它是一个文件而不是目录，或者java进程没有读取权限）。类似地，delete()不会抛出异常。相反，它返回false来指示失败。这不仅不像java，这也意味着它是不可能知道 * 为什么 * delete()不工作.访问权限问题？文件不存在？谁知道.
简单的结论是，你应该总是检查你对j.i.File对象所做的任何事情的返回值，但这是一种捷径。真正的解决办法是停止使用它。
新的API也有问题，但问题要少得多。它也不是过时的/在英语字典意义上的过时：这就是一个最先进的java应用程序应该如何与文件进行交互，你可以在java.nio.file包中找到它。
与j.i.File API不同，这个API在出错时会抛出异常，这些异常会告诉你，程序可检查（一种类型层次结构，如NoSuchFileException，如果你想专门对这样的问题做出React），以及人类可检查，因为这些异常的消息用英语解释了什么是错误的。
其次，你必须安全地关闭表示系统资源的对象，而你的代码不会这样做。有一个方便的try-with语法可以让这变得容易，所以让我们也这样做吧！
第三，你是冲了再关，这是毫无意义的;close()已经隐含了flush，没有理由在close之前 ever 调用flush（），它只会让你的代码变得混乱。事实上，使用try-with根本不需要close。
因此：

Path tempFile = Paths.get("temp.txt");
Path saveFile = Paths.get("save.txt");
try (
  Writer fw = Files.newBufferedWriter(tempFile, StandardOpenOption.APPEND);
  BufferedReader br = Files.newBufferedReader(saveFile);
  ) {

  String line;
  while ((line = br.readLine()) != null) {
    if (line.equals(player.username)) continue;
    fw.write(line);
    fw.write("\n");
  }
}

Files.delete(saveFile);
Files.move(tempFile, saveFile);