应有选择地截断异常链以保留业务栈帧并维护cause关系：识别并跳过java.、sun.、spring、servlet等无意义栈帧，从首个业务包（如com.yourcompany.*）起向上保留；递归裁剪整条异常链，用构造函数传递裁剪后的cause；白名单配置+兜底策略确保鲁棒性；日志前统一处理，禁用丢弃cause的重抛。
保留异常链的完整性，同时剔除无意义的系统内部栈帧（比如 JDK、Spring、Servlet 容器等底层调用），关键在于“有选择地截断”而非“简单丢弃”。核心思路是：只保留业务相关栈帧，过滤掉纯框架/基础设施层的调用，但不破坏 cause 链路关系。
识别并跳过典型无意义栈帧
Java 异常链中，以下类包前缀的栈帧通常与业务逻辑无关，可安全裁剪：
-
java.*（如
java.lang.Thread.run、java.util.concurrent线程调度） - sun.* 和 jdk.*（JVM 内部实现）
- org.apache.catalina.*、org.springframework.web.servlet.*、org.springframework.aop.*（Web 容器与 Spring MVC/AOP 框架入口）
- net.bytebuddy.*、org.springframework.cglib.*（动态代理生成的桥接方法）
注意：裁剪时不能直接删除整个 StackTraceElement[] 数组，而应从原始栈中提取出首个“业务包”起始位置，并向上保留到该位置——确保异常抛出点仍在链中。
重构异常链，而非仅过滤栈数组
单纯调用 setStackTrace() 只影响当前异常的栈，无法修复 cause 的冗余。正确做法是递归遍历整个异常链，对每个异常独立裁剪其栈帧，并重建父子引用：
- 从最内层异常（root cause）开始处理，裁剪其栈帧，生成新异常实例（保持原类型、消息、cause）
- 逐层向外，为每个包装异常创建新实例，将已裁剪的下层异常设为
cause - 避免使用
initCause()（可能被 final 修饰限制），优先用构造函数传入cause
例如：new RuntimeException("biz fail", trimmedCause)，其中 trimmedCause 已是裁剪后的异常实例。
定义“业务包名”白名单，避免硬编码过滤
把业务代码所在包（如 com.yourcompany.order、com.yourcompany.payment）配置为白名单，裁剪策略改为：“从栈底向上扫描，找到第一个属于白名单的栈帧，从此处截断，保留其上方所有帧（含它自己）”。这样能自动适配不同模块的入口点，也兼容未来新增服务包。
- 支持通配符，如
com.yourcompany.* - 若整条栈都未命中白名单，退化为保留最底部 3~5 帧 + 最顶部 2 帧（防止全空）
- 日志上报前统一执行该裁剪，而非仅在 catch 块里临时处理
慎用“压制”和“重抛”，避免隐式丢失 cause
不要写 throw new RuntimeException(e.getMessage()) 这类丢弃 cause 的代码；也不要依赖 Throwable.addSuppressed() 来“补充”信息——它不参与主 cause 链，排查时容易被忽略。
- 必须保留 cause 时，始终显式传递，如
new ServiceException("order create failed", e) - 若需增强异常信息，用装饰模式包装，而不是替换：继承原异常类型或封装为自定义异常，且构造函数中完整委托 cause
- 全局异常处理器（如 Spring 的
@ControllerAdvice）中做最终裁剪，确保所有出口一致
