java 7多异常捕获需满足互不相关的已检查或运行时异常、用|分隔、e为最近公共父类；不支持父子类异常合并；无法直接调用子类特有方法，需instanceof判断；性能与多个catch无差异；适用于处理逻辑完全一致的场景。
Java 7 多异常捕获语法写不对，编译直接报错
Java 7 引入的 catch (ExceptionA | ExceptionB e) 是合法语法，但必须满足两个硬性条件：所有异常类型必须是**互不相关的已检查异常或运行时异常**，且不能是同一类的父子关系。比如 IOException | SQLException 可以，但 IOException | FileNotFoundException 不行——后者编译报错 Catch parameter has redundant type，因为 FileNotFoundException 是 IOException 的子类。
- 只支持用
|分隔，不能用||或逗号 - 捕获变量
e的静态类型是这些异常的**最近公共父类**（通常是Exception或Throwable），所以调用子类特有方法会编译失败 - 如果其中一个是未检查异常（如
RuntimeException），整个catch块仍可捕获它，但不会影响方法签名中throws的声明逻辑
多异常捕获后无法调用具体异常的方法
这是最常被忽略的设计后果：e 的类型不是你列出来的任一具体异常，而是它们的最小公共超类。比如 catch (SQLException | IOException e) 中，e 类型是 Exception，不能直接调用 e.getSQLState() 或 e.getLocalizedMessage() 以外的子类方法。
- 需要判断类型再强转：用
if (e instanceof SQLException)分支处理，但这就削弱了语法糖的价值 - 日志记录时建议统一用
e.getClass().getSimpleName()+e.getMessage()，避免假定行为 - 如果业务逻辑严重依赖异常子类字段（如 SQL 错误码、HTTP 状态码），多异常捕获反而增加维护成本，不如分开
catch
和传统多个 catch 块比，性能有区别吗
没有运行时性能差异。JVM 在字节码层面把多异常捕获编译为多个独立的异常处理器（exception handler），和手写多个 catch 块生成的指令几乎一致。差别只在源码可读性和编译期检查。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
-
javac 编译后，
catch (A | B e)和分别写两个catch在 class 文件里都是多个ExceptionHandler条目 - 启动时类加载、异常分发路径完全相同，别信“更轻量”的说法
- 真正影响性能的是异常本身被抛出——无论怎么捕获，构造堆栈、填充上下文才是开销大户
哪些场景适合用，哪些该避开
适合用在「错误处理逻辑完全一致」的多个异常上，比如统一关闭资源、记录基础日志、转成同一业务异常。一旦分支处理逻辑开始分化，就该退回传统写法。
- 推荐场景：网络请求中同时捕获
SocketTimeoutException和ConnectException，都重试一次 - 推荐场景：文件操作中捕获
FileNotFoundException和SecurityException，都返回 HTTP 404 - 回避场景：需要对
SQLException解析错误码，但对IOException只做重试——此时合并反而让逻辑缠绕 - 回避场景：其中一个异常是自定义业务异常（如
InsufficientBalanceException），另一个是框架异常（如RemoteAccessException）——语义层级不同，强行合并易误导后续维护者
多异常捕获不是“必须用”的新特性，它是给特定重复模式减负的工具。写的时候多问一句：如果下周我得改其中一种异常的处理方式，现在这个 | 写法会让改动更简单，还是更难？
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
