Java多catch合并（|语法）不涉及varargs传递，仅简化异常捕获写法；e是单个final异常实例，可直接传入varargs方法，但静态类型为公共父类，影响重载选择。
Java中多catch语句块合并（即使用 | 语法）本身**不涉及可变参数（varargs）的传递**，也不会改变方法调用时可变参数的绑定或行为。它只影响异常捕获的写法和变量语义，与方法签名中的 ... 参数无直接关联。混淆常源于将“异常参数”误当作“方法参数”，需明确区分。
多catch合并不改变方法调用上下文
可变参数是方法声明层面的特性（如 void log(String msg, Throwable... causes)），而多catch中的 e 是异常处理作用域内的局部变量，两者生命周期、作用域、绑定时机完全不同。即使在 catch 块内调用含 varargs 的方法，传入的仍是原始异常对象或其包装结果，与多catch语法无关。
- 多catch只是把多个独立 catch 块的共性逻辑合并书写，并未引入新参数或修改调用栈
- 你在
catch (IOException | SQLException e)中拿到的e是一个具体异常实例（比如SQLException），可直接作为单个参数传给 varargs 方法：log("DB or IO failed", e)—— 此时e被自动装入 varargs 数组，和普通调用完全一致 - 不存在“合并后导致 varargs 接收多个异常”的情况：每次
catch块最多只捕获一个异常，e永远是单个对象引用
异常变量 e 是 final，但不影响 varargs 使用
多catch 中的异常参数 e 是隐式 final，意味着你不能给它重新赋值（如 e = new RuntimeException()），但这仅限制对引用本身的修改，**完全不妨碍将其作为实参传入任何方法，包括接受 varargs 的方法**。
-
e的不可变性保护的是异常信息完整性，不是阻止你使用它 - 你可以安全调用：
logger.error(msg, e)、throw new ServiceException(e)、notifyAdmin("Error", e)，只要目标方法签名兼容 - 若需传多个异常（如主异常 + 补充原因），应显式构造数组或列表，再传给 varargs 方法，例如：
log("Failed with context", e, new IllegalArgumentException("context invalid"))
真正影响 varargs 传递的，是异常类型推导与方法重载
当合并捕获的异常类型不同（如 IOException 和 SQLException），它们的最小公共父类通常是 Exception。这会影响编译期对方法重载的选择，尤其当存在多个同名但参数类型不同的 log 方法时：
立即学习“Java免费学习笔记（深入）”；
- 如果定义了
log(String, IOException)和log(String, SQLException)，但你在多catch中用e调用log("msg", e)，编译会失败——因为e类型是Exception，无法精确匹配任一重载 - 此时应统一使用接受
Throwable或Exception的版本，或改用 varargs 版本：log(String, Throwable...)，它能接收任意数量和类型的异常 - 避免依赖子类特有方法：因
e静态类型为公共父类，不能直接调用e.getSQLState()等子类方法；若需差异化处理，应在合并前拆分 catch，或用instanceof判断后再传参
实际编码建议
多catch 合并适合统一响应场景，与 varargs 协同使用时，重点在于接口设计清晰：
- 对外提供日志/通知方法时，优先定义
void log(String, Throwable...)，而非多个单参数重载 - 在多catch块中，直接传
e即可，无需额外包装；若需补充上下文，新建异常并以e为 cause，再传入 varargs 方法 - 不要试图在 catch 块内通过修改
e来适配 varargs —— 它不可赋值，且修改引用无意义；应创建新对象 - 检查工具链（如 Checkstyle）是否将空 catch 或未使用
e视为问题；即使用了 varargs，也要确保异常被记录或传播
