ioexception是受检异常，必须try-catch或throws声明，否则编译失败；files.readstring()等方法将其转为uncheckedioexception，虽免编译检查但运行时仍崩溃，且utf-8默认解码可能导致gbk中文乱码。
Java中IOException为什么总在编译时报错
因为IOException是受检异常（checked exception），JVM强制要求你显式处理——要么用try-catch捕获，要么在方法签名里用throws声明。不这么做，代码根本编译不过。
常见错误现象：直接调用FileInputStream构造函数或Files.readAllBytes()却不处理异常，IDE立刻报红，提示“Unhandled exception: java.io.IOException”。
- 不是所有IO操作都抛
IOException：比如new File("path").exists()不抛，它只返回boolean - Java 7+ 的
Files工具类多数方法（如Files.copy()、Files.delete()）都声明抛IOException，但Files.exists()不抛 -
PrintWriter默认吞掉异常（checkError()才暴露），容易误以为“没出错”，实际写入可能已失败
用try-with-resources自动关闭流，但要注意嵌套资源的释放顺序
手动close()容易遗漏或放在catch块外导致未执行；try-with-resources能保证资源在离开作用域时按声明**逆序**关闭（后声明的先关），避免IOException在close()时掩盖主逻辑异常。
典型场景：读文件并解析JSON，需同时管理FileInputStream和InputStreamReader。
立即学习“Java免费学习笔记（深入）”；
try (FileInputStream fis = new FileInputStream("data.json");
InputStreamReader reader = new InputStreamReader(fis, StandardCharsets.UTF_8)) {
// 解析逻辑
} catch (IOException e) {
// 所有close()失败都会合并到这个e里（通过addSuppressed）
}
- 多个资源用分号隔开，它们必须实现
AutoCloseable - 如果第一个资源构造就失败（如文件不存在），第二个不会实例化，自然也不触发关闭
- 不要在
try块里对资源变量重新赋值，否则原对象无法被自动关闭
Files类的readString()和writeString()简化了异常处理，但仍有陷阱
Java 11 引入的Files.readString()看起来“不用管异常”，其实只是把IOException包装成UncheckedIOException再抛出——它继承自RuntimeException，编译器不强制处理，但运行时仍会崩。
这意味着：你省了try-catch，但没省掉错误处理责任；线上一旦路径错、权限不足、磁盘满，服务就直接500。
-
Files.readString(Path)内部仍可能抛IOException，只是转成了运行时异常 - 它默认用UTF-8解码，若文件是GBK且含中文，会乱码——但不会报异常，只会静默损坏数据
-
Files.writeString()默认覆盖写入，没有CREATE_NEW选项，想确保不覆盖得自己加StandardOpenOption.CREATE_NEW
捕获IOException时，别只打日志就完事
很多代码写成catch (IOException e) { logger.error("", e); }，看似处理了，实则丢失关键上下文：哪个文件？什么操作？权限还是路径问题？
更务实的做法是记录可定位的信息，并根据场景决定是否重试或降级。
- 在
catch块里补全操作描述："Failed to read config file: " + path.toString() - 区分具体子类：比如
FileNotFoundException可提示用户检查路径，AccessDeniedException（继承自IOException）说明权限问题，应查OS级设置 - 网络文件系统（NFS/SMB）上IO异常常瞬时发生，对
read/write操作可考虑简单重试（最多1–2次），但delete不能盲目重试
复杂点往往不在语法——而在于你是否清楚每个IOException背后对应的真实系统状态。
