构造函数在创建异常对象时一次性绑定cause，initCause则在对象创建后补设且仅限未设过cause的情况；前者属初始化阶段，后者为事后干预，均写入同一cause字段但调用时机与约束不同。
本质区别就一点：构造函数是在创建异常对象时“一次性绑定”根本原因，initCause 是在对象创建后“补设”原因，且仅限未设过 cause 的情况。
调用时机与初始化阶段不同
构造函数参与对象实例化全过程，cause 字段在 new 表达式执行时就完成赋值；initCause 则是对象已存在、处于可操作状态后才被调用的方法。
- 构造函数属于对象生命周期的“出生时刻”，天然具备设置 cause 的能力
- initCause 属于“事后干预”，必须确保对象尚未通过构造器设置 cause，否则直接失败
- 两者都写入同一个 cause 字段，但 initCause 前会强制校验 this.cause == null
适用场景有明确边界
不是所有异常对象都能用 initCause，它只对两类异常有效：无参构造的（new Exception()）或仅带 message 构造的（new IOException("timeout")）。
- 若异常类本身提供了 Throwable cause 参数的构造器（如 RuntimeException(String, Throwable)），应优先使用它
- initCause 主要用于老项目兼容、AOP 异常拦截包装、泛型擦除后无法直接传 cause 的场景
- 自定义异常未实现带 cause 构造器时，initCause 是唯一补救手段
行为约束与失败风险差异明显
构造函数没有重复调用问题，而 initCause 一旦调用成功，再次调用必然抛出 IllegalStateException。
立即学习“Java免费学习笔记（深入）”；
- 构造函数设置 cause 是单向、不可逆、无副作用的操作
- initCause 内部会检测循环引用（比如 e.initCause(e)），也会拒绝 null 以外的重复赋值
- 某些框架或容器中异常对象可能已被冻结（如序列化后），此时调用 initCause 会静默失败或抛 UnsupportedOperationException
底层字段操作逻辑一致但入口不同
cause 字段在 Throwable 中声明为 private Throwable cause = this，并非 final，所以两种方式最终都是直接赋值 this.cause = xxx。
- 构造函数走的是 JVM 初始化路径，initCause 走的是普通方法调用路径
- 传入 null 时，两者都会将 cause 设为一个内部静态占位对象 UNASSIGNED_CAUSE，而非真正的 null
- 打印堆栈或调用 getCause() 时，用户完全感知不到二者底层实现差异
