initCause 与 JUnit 断言失败无关，它是 Throwable 的普通方法，用于手动设置异常根本原因；JUnit 断言失败靠抛出 AssertionError 实现，测试运行器捕获后标记失败并输出对比信息。
initCause 不是 JUnit 断言失败的触发机制，也不在 JUnit 底层用于报告断言失败；它属于 Java Throwable 类的普通方法，用于手动设置异常的“根本原因（cause）”，和 JUnit 的断言执行、失败判定、错误报告无直接关系。
JUnit 断言失败的本质是抛出 AssertionError
当调用 assertEquals、assertTrue 等断言方法且条件不满足时，JUnit 会主动抛出 AssertionError（继承自 Error），测试运行器捕获该异常后即标记测试为失败，并输出堆栈和预期/实际值对比。这个过程完全不涉及 initCause。
initCause 的真实用途：构造带嵌套原因的异常
该方法仅在开发者**手动创建并组装异常链**时使用，典型场景包括：
- 封装底层异常时保留原始根因：比如业务方法捕获了
SQLException，再抛出新的ServiceException，并用initCause把 SQL 异常设为其 cause - JUnit 测试中验证该异常链是否正确构建（此时
initCause是被测代码的一部分，不是 JUnit 自身行为）
JUnit 中验证 cause 的正确方式是 getCause()，不是 initCause()
若要测试某异常是否具有预期的根本原因，应使用断言检查其 getCause() 返回值，例如：
立即学习“Java免费学习笔记（深入）”；
Exception actual = assertThrows(ServiceException.class, () -> service.doSomething());<br>assertThat(actual.getCause()).isInstanceOf(SQLException.class);
或原生 JUnit 写法：
Throwable thrown = assertThrows(ServiceException.class, () -> service.doSomething());<br>assertTrue(thrown.getCause() instanceof SQLException);
常见误解澄清
有人误以为 initCause 可用于“让断言失败时附带更多信息”，这是不成立的。断言失败信息由 JUnit 自动组装（如 expected:<1> but was:<2>），无需、也不应通过手动操作异常 cause 来干预。强行在断言逻辑里调用 initCause 不但无效，还可能因重复设置 cause 抛出 IllegalStateException，干扰测试流程。
