核心是确保cause字段被正确、及时、一次性绑定到新异常上，优先使用带cause的构造器（如throw new ServiceException("msg", e)），自定义异常须显式调用super(message, cause)，避免initCause()或消息拼接。
要在异常链中真正保留原始异常堆栈信息，核心不是“选 initCause 还是构造器”，而是**确保 cause 字段被正确、及时、一次性地绑定到新异常上**。Java 的 printStackTrace() 和日志框架（如 SLF4J）依赖这个字段展开 “Caused by” 层级，而堆栈轨迹本身在原始异常创建时就已固化——你只需让它可被追溯。
优先用带 cause 的构造器，这是最安全自然的方式
所有标准异常（RuntimeException、IOException、SQLException 等）和规范编写的自定义异常，都提供 Exception(String message, Throwable cause) 构造器。它在对象初始化阶段就完成 cause 绑定与堆栈填充，线程安全且无状态风险。
- ✅ 正确示例：
throw new ServiceException("支付失败", e); - ✅ 自定义异常必须显式支持：
public class ServiceException extends RuntimeException {
public ServiceException(String message, Throwable cause) {
super(message, cause); // 关键：把 cause 传给 Throwable 父类
}
} - ❌ 避免拼接消息：
new ServiceException("支付失败: " + e.getMessage())—— 丢失堆栈、丢失 cause、无法调用getCause()
initCause() 只适用于特定补救场景，不能当作常规手段
initCause() 是 JDK 1.4 为兼容老代码设计的“兜底机制”，仅在以下三个条件同时满足时才合法且必要：
- 异常对象已通过无参或单参（仅 message）构造器创建，尚未抛出
- 该异常类没有提供
(String, Throwable)构造器（如IllegalArgumentException、某些第三方 SDK 异常） - 其
getCause()返回null或this（即 cause 尚未初始化）
例如：
立即学习“Java免费学习笔记（深入）”；
try {loadConfig();
} catch (IOException e) {
IllegalArgumentException iae = new IllegalArgumentException("配置加载异常");
iae.initCause(e); // ✅ 合法：iae 刚建，cause 为空
throw iae;
}
千万别踩的坑：破坏链路的常见错误
- 在
catch块里对已捕获的异常调用initCause()—— 它的 cause 通常已在构造时设好，再调必抛IllegalStateException - 重复调用
initCause()—— 即使第一次传null，也会锁定 cause 状态，后续调用全部失败 - 只记录
e.getMessage()或e.toString()到日志 —— 日志里看不到 “Caused by”，审计时无法定位根因 - 响应前端时直接透传原始异常 message —— 泄露数据库表名、路径、内部类等敏感信息
验证是否成功保留堆栈的关键动作
写完异常包装逻辑后，做一次快速验证：
- 运行时调用
e.printStackTrace()，确认输出包含清晰的 “Caused by: …” 行，并逐层显示各异常的类、方法、行号 - 在日志中使用
log.error("业务操作失败", e)（而非拼接 message），检查日志文件是否完整打印嵌套堆栈 - 调试时调用
e.getCause()，确认能拿到原始异常；再对其调用getCause()，看是否可继续向下追溯
