IOException是受检异常，编译器强制要求try-catch或throws，否则编译失败；而NullPointerException等非受检异常编译期不检查，仅运行时抛出。

因为IOException是受检异常，Java编译器在编译阶段就强制要求你表明态度：要么当场处理，要么明确声明风险。不写try-catch也不加throws，代码根本通不过编译。

受检异常的编译期“硬拦截”

Java把异常分成两类，关键区别就在编译器是否插手：

• 受检异常（如IOException、SQLException）——继承Exception但不是RuntimeException子类，编译器会逐行检查：只要调用了可能抛它的API（比如new FileReader("x.txt")），又没包进try-catch，也没在方法签名写throws IOException，javac立刻报错：
  error: unreported exception IOException; must be caught or declared to be thrown
• 非受检异常（如NullPointerException、ArrayIndexOutOfBoundsException）——属于RuntimeException分支，编译器完全不管，代码照常编译，只在运行时才暴露问题

为什么偏偏对IO操作这么“较真”？

设计者认为I/O失败不是程序写错了，而是环境不可靠（磁盘满了、网络断了、文件被删了），这类问题可预见、可恢复，不该被忽略：

• 如果IOException是运行时异常，大量read/write调用可能静默失败——表面没报错，实际数据没落盘、请求没发出去
• 强制显式处理，等于逼你在代码里留下决策痕迹：是重试？切备用路径？还是告诉用户“文件找不到了”？
• FileNotFoundException、SocketTimeoutException这些子类，同样继承自IOException，也必须一视同仁地处理

throws和try-catch不是替代关系，是职责分工

选哪个，取决于你在哪一层、能做什么决定：

• 底层工具方法（比如封装一个读JSON的静态工具）适合用throws IOException：它不假设上层怎么恢复，只负责暴露风险
• 业务入口点（比如Spring Controller的接口方法）通常得用try-catch：要记录日志、返回HTTP 500或友好提示，不能把异常一路甩给前端
• 注意：try-with-resources只保证资源自动关闭，reader.readLine()抛的IOException仍需捕获或声明，不能以为加了try (Resource r = ...)就万事大吉

常见踩坑提醒

看似处理了，其实等于没做：

• catch (IOException e) { e.printStackTrace(); }——控制台输出在生产环境基本看不到，也没恢复动作，属于假装处理
• 在循环里对每次write()单独套try-catch——某次写失败被吞掉，后续数据继续写，结果部分丢失却无感知
• lambda里直接调用Files.readAllBytes()——它抛受检异常，但lambda无法声明throws，编译直接失败，得包装成自定义运行时异常或改用其他方式