initCause()仅能调用一次，由Throwable内部cause字段状态与fillInStackTrace()执行时机共同约束；构造器传cause更安全，因对象创建时堆栈未填充、状态干净，天然避免重复设置。
initCause() 只能调用一次，不是靠计数器或外部锁实现的，而是由 Throwable 内部状态和堆栈填充时机共同决定的底层约束。
底层控制逻辑：cause 字段 + 初始化状态检查
Throwable 类中有一个私有字段 cause，初始值为 this（即自身），表示“无外部原因”。调用 initCause(c) 时，JVM 会执行三重校验：
- 检查当前 cause 是否仍为 this 或 null —— 否则说明已被设置过，直接抛 IllegalStateException
- 检查传入的 c 是否为当前异常本身 —— 防止循环引用，抛 IllegalArgumentException
- 检查 fillInStackTrace() 是否尚未执行 —— 因为一旦堆栈快照冻结，再修改 cause 可能引发线程安全问题或静默失效
为什么构造函数传 cause 更安全？
使用带 Throwable cause 参数的构造器（如 new Exception("msg", original)）是在对象创建瞬间完成 cause 赋值，此时堆栈尚未填充、状态绝对干净。而 initCause() 是事后补救，依赖开发者手动保证调用时机和前提条件。
- 构造器方式天然规避重复设置风险
- 编译期可配合 Lombok @AllArgsConstructor 或 IDE 提示，减少漏传
- SonarLint 等工具默认推荐构造器方式，视为更合规的异常链写法
规避误用的实用策略
不靠记忆，靠结构化防护：
立即学习“Java免费学习笔记（深入）”；
- 自定义异常类统一提供带 cause 的构造器，并在 Javadoc 中注明“禁止调用 initCause()”
- 在通用异常包装工具方法中，先判空：if (e.getCause() == null) { e.initCause(original); }
- 日志记录前主动展开 cause 链，避免依赖上层代码做递归判断
- 单元测试中对关键异常路径断言 getCause() 不为 null，形成质量卡点
Netty 等动态场景下的合理例外
当异常对象必须在运行时按条件创建（如 IdleStateEvent 触发后才决定抛什么异常），且原异常类未预设 cause 构造器时，initCause() 是标准解法。
- 确保只在 new 之后、throw 之前立即调用
- 避免在 finally 块、异步回调或日志拦截器中调用 —— 状态不可控
- 可封装一层 SafeInitCauseUtils.init(e, cause)，内部做判空+try-catch，防止崩溃扩散
