initCause()用于为已创建但未抛出的异常手动设置根本原因，仅限无参或单字符串构造的异常调用一次；若构造器已支持cause参数（如RuntimeException(String, Throwable)），应优先使用构造器而非initCause()。
Java里怎么用 initCause() 把原始异常串起来
直接说结论：initCause() 是给一个已创建但还没抛出的异常对象手动设置根本原因（cause）的方法，但它只能调用一次，且目标异常的构造函数没自带 cause 参数时才需要它。
常见错误现象是：调用两次 initCause() 抛出 IllegalStateException: Cause already initialized；或者在已经用带 Throwable 参数的构造器创建的异常上调用，直接失败。
- 只对通过无参构造器或单字符串构造器创建的异常有效，比如
new RuntimeException()、new IOException("timeout") - 如果异常类本身支持传
cause（如new RuntimeException("msg", cause)），优先用构造器，别绕路initCause() - 调用后不能再次调用，也不能在
cause已由构造器设好的实例上调用，否则抛异常
为什么有时候必须用 initCause() 而不是构造器
核心场景就一个：你手头只有一个“半成品”异常对象（比如从框架回调里拿到的、或泛型擦除后只剩 Exception 类型），但此时原始异常才刚捕获到，需要动态挂上去。
典型例子是 AOP 拦截异常后统一包装，又不想丢原始堆栈；或是某些老版本 JDK（如 Java 6）里自定义异常没实现带 cause 的构造器，只能靠 initCause() 补救。
立即学习“Java免费学习笔记（深入）”；
- Java 7+ 推荐所有自定义异常都实现
Throwable(String, Throwable)构造器，避免依赖initCause() -
initCause()是Throwable的 final 方法，子类无法重写，行为稳定但灵活性低 - 反射或序列化场景下，若异常对象已被冻结（如
writeObject后），再调initCause()会失败
initCause() 和 getCause() 配合查根因的实际写法
链式异常不是自动展开的，打印日志或调试时得主动调 getCause() 一层层挖，否则只看到最外层包装。
示例：捕获 SQLException 后包装成业务异常，再手动挂上原始异常：
try {
// DB 操作
} catch (SQLException e) {
BusinessException bizEx = new BusinessException("订单创建失败");
bizEx.initCause(e); // ✅ 此时 e 是根因
throw bizEx;
}
后续处理时，要定位真实问题，得这样追溯：
- 用
e.getCause()拿第一层原始异常（这里是SQLException） - 再对它调
getCause()，可能还有更底层的IOException或驱动内部异常 - 日志框架（如 Logback）默认只打最外层，需配置
%ex{full}或手动循环打印
容易被忽略的兼容性和副作用
initCause() 看似简单，但和异常传播、线程上下文、监控系统深度耦合，几个关键点常被跳过：
- 某些监控 SDK（如早期 Sentry Java SDK）只抓
throw时的栈，不自动递归采集cause，导致告警里看不到根因 - Android 低版本（API initCause() 在部分系统异常上无效，因为底层
Throwable实现被修改过 - 如果在
finally块里对异常反复调initCause()，可能掩盖真正触发点，让排查变困难
最麻烦的是：当异常被多次包装、又混用构造器和 initCause() 时，getCause() 返回 null 并不意味着没根因——可能是某次调用失败静默吞掉了，得翻源码确认构造路径。
