Java包装异常需封装原始Throwable为cause并补充业务消息，避免暴露敏感信息；日志和API响应中须剥离敏感字段，禁用递归序列化堆栈；ExceptionUtils可简化链式处理但不自动脱敏；异步场景需手动传入cause以保留准确堆栈。
Java中包装异常时为什么不能直接抛出原始Throwable
底层异常（比如SQLException、IOException）通常携带敏感信息（数据库URL、表名、文件路径），直接暴露给上层或前端可能引发安全风险。更关键的是，调用方往往不关心底层实现细节，只关心“操作失败了”，所以需要把原始异常作为cause封装进业务语义明确的新异常里。
常见错误是写成：
throw new RuntimeException(e);——这会丢失原始异常的堆栈起点，且没提供任何上下文。正确做法是显式传入
cause并补充有意义的消息：
new ServiceException("订单创建失败", e)new IllegalArgumentException("用户ID不能为空", e)- 自定义异常类必须有带
Throwable参数的构造函数，并调用super(message, cause)
如何让包装后的异常保留原始堆栈但隐藏敏感字段
Java默认的异常链机制（getCause() + printStackTrace()）本身就能保留完整堆栈，但问题出在日志打印或API响应时可能序列化整个Throwable对象，导致toString()输出里包含原始异常的字段值。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 日志中避免直接
log.error("xxx", e)——Logback/Log4j 默认会打印cause，可改用log.error("订单保存异常: {}", e.getMessage())控制主消息 - 对外返回的错误响应体，只取
e.getMessage()和自定义错误码，**绝不**递归序列化e.getCause().getStackTrace() - 若需调试，可在内部日志中记录
e.getCause().toString()，但生产环境关闭该行
使用ExceptionUtils（Apache Commons Lang）简化异常包装
手动处理异常链容易漏掉cause或消息拼接错误。ExceptionUtils提供几个实用方法：
-
ExceptionUtils.getRootCause(e)：拿到最底层异常（比如SQLException），用于分类处理 -
ExceptionUtils.getStackTrace(e)：获取全链堆栈字符串，仅限调试日志，不用在响应体中 - 配合
Optional.ofNullable(e.getCause()).map(Throwable::getMessage).orElse("")安全提取原因消息
注意：ExceptionUtils不会自动过滤敏感内容，它只是工具，敏感字段仍需业务层主动剥离。
自定义异常类必须重写fillInStackTrace()吗
不需要，也不建议重写。Java异常的堆栈是在new时由JVM自动填充的，重写fillInStackTrace()会清空当前帧，反而让定位变难。真正要关注的是：在什么位置包装、是否保留原始cause、消息是否含可操作线索。
容易被忽略的一点：如果在异步线程（如CompletableFuture）中包装异常，原始异常的堆栈起点仍是异步任务提交处，不是实际出错行——这时需在exceptionally里重新new异常并手动传入cause，否则堆栈会指向ForkJoinPool内部。
