Java输入输出流异常处理需精准捕获Checked异常、用try-with-resources自动关流、错误信息业务化、禁用异常作流程控制。
Java 中输入输出流异常必须规范处理，核心是兼顾资源安全、错误可读和代码简洁。重点不是“有没有 try-catch”，而是“捕获是否精准、资源是否必关、错误是否可诊断”。
明确区分 Checked 异常并分层捕获
IO 操作抛出的主要是 Checked 异常，如 FileNotFoundException 和 IOException。它们不是程序 bug，而是外部环境问题，必须显式应对。
- 优先单独捕获
FileNotFoundException：说明路径无效或文件不存在，适合引导用户检查路径、提供默认配置或创建空文件 - 再用
IOException捕获其他 IO 问题：如磁盘满、权限不足、网络中断等，统一记录日志并提示“操作失败，请重试” - 避免只写
catch (Exception e)：会掩盖真实原因，也违反阿里巴巴开发规约
用 try-with-resources 替代手写 finally 关流
JDK 7 起，所有实现 AutoCloseable 的流（如 FileInputStream、BufferedReader、PrintWriter）都应使用 try-with-resources，它在语句块结束时自动调用 close()，且能正确处理多个资源和异常抑制（suppressed exception）。
- 写法示例：
try (BufferedReader br = new BufferedReader(new FileReader("data.txt"))) { ... } - 不需手动判空、不需写 finally、不需嵌套 try-catch 关流
- 若需兼容 JDK 6 或自定义非 AutoCloseable 资源，才退回到传统 finally 手动关闭
异常信息要业务化，不暴露技术细节
向用户或上层返回的错误消息不能直接用 e.getMessage()，尤其不能泄露绝对路径、系统用户名、堆栈或数据库结构。
立即学习“Java免费学习笔记（深入）”；
- 对内记录完整日志：
logger.error("读取配置文件失败", e)（保留堆栈） - 对外返回友好提示：
"配置文件加载异常，请确认文件存在且格式正确" - 必要时包装为自定义业务异常，如
ConfigLoadException，携带上下文字段（如文件名、行号）
不把异常当流程控制手段
不要用 FileNotFoundException 来判断文件是否存在——这属于反模式。应先用 Files.exists() 或 File.exists() 主动检查，再打开；否则每次“不存在”都会触发一次异常抛出与捕获，性能差且语义不清。
- 例外情况：仅当“存在即成功、不存在即终止”且检查成本高（如 NFS 远程路径）时，才接受该异常作为逻辑分支
- 更推荐：用
Files.isReadable()+Files.newInputStream()组合，语义清晰、开销可控
