使用 StringWriter + PrintWriter 是捕获异常堆栈为字符串最稳妥的方式，JDK 1.4+ 兼容，自动处理 cause 链和 suppressed 异常，且不依赖第三方库。
用 StringWriter + PrintWriter 捕获堆栈到字符串
Java 默认不提供直接把异常堆栈转成字符串的 API，但组合 StringWriter 和 PrintWriter 是最稳妥、兼容性最好的方式。它不依赖日志框架，也不需要反射或内部类，JDK 1.4+ 全支持。
常见错误是直接调用 e.toString() 或 e.getMessage() —— 这俩都只返回异常类型和消息，完全没堆栈；还有人误用 e.getStackTrace() 手动拼接，结果丢掉 cause 链和本地化信息。
- 必须用
PrintWriter的printStackTrace()重载方法，传入PrintWriter实例，不能只靠toString() - 记得在写完后调用
pw.close()（或 try-with-resources），否则缓冲区可能不刷新 - 如果异常有嵌套
cause，这个方案自动递归打印，无需额外处理
Throwable e = new RuntimeException("boom", new NullPointerException());
StringWriter sw = new StringWriter();
try (PrintWriter pw = new PrintWriter(sw)) {
e.printStackTrace(pw);
}
String stackTrace = sw.toString(); // 包含完整堆栈和 cause
避免 ExceptionUtils.getStackTrace() 的陷阱
Apache Commons Lang 的 ExceptionUtils.getStackTrace() 看起来方便，但它在 JDK 9+ 上可能抛 NoClassDefFoundError，因为底层用了已移除的 sun.misc.SharedSecrets 相关逻辑（尤其在模块化环境或某些 GraalVM 场景下）。
更隐蔽的问题是：它默认不包含 suppressed 异常（即 try-with-resources 中被抑制的异常），而原生 printStackTrace() 在 JDK 7+ 是包含的。
立即学习“Java免费学习笔记（深入）”；
- 如果你项目已强依赖 Commons Lang 且版本 ≥ 3.12.0，问题不大；但新项目建议绕开，减少间接依赖
- 若必须用，确认
getFullStackTrace()而非getStackTrace()，后者会截断 cause 链 - 永远别在日志格式化中无条件调用它——万一静态初始化失败，连日志都打不出来
Log4j2 / SLF4J 中记录堆栈的正确姿势
日志框架不是用来“生成”堆栈字符串的，而是用来“传递”异常对象。直接传 exception 参数，让框架自己处理，比手动转字符串更可靠。
典型错误是写成：log.error("failed: " + e.toString())，或者更糟：log.error("failed", e.toString()) —— 后者把字符串当异常传，框架根本不会解析堆栈。
- SLF4J 正确写法：
log.error("operation failed", e)（第二个参数是Throwable） - Log4j2 同理：
logger.error("operation failed", e)，确保使用了带Throwable的重载方法 - 如果非得在 MDC 或 JSON 日志里塞堆栈字符串，请用第一种
StringWriter方式，并限制长度（比如只取前 4KB），避免日志爆炸
性能敏感场景下要不要缓存堆栈字符串？
不要。每次调用 printStackTrace() 生成字符串的成本，主要花在遍历 StackTraceElement[] 和字符串拼接上，本身很快（微秒级）。但缓存它反而引入线程安全问题和内存泄漏风险——比如把堆栈字符串存在 static map 里，又忘了清理。
真正慢的是序列化、网络发送、磁盘刷写这些后续环节，不是生成这串文本本身。
- 除非你每秒抛出上万异常并全部记录（那该先查为什么异常这么多）
- 别为“看起来重复”提前优化；堆栈内容本身是动态的（行号、局部变量名等可能变）
- 如果日志异步，框架通常已做缓冲；手动缓存只是增加复杂度
最常被忽略的一点：有些 APM 工具（如 SkyWalking）会自动采集异常堆栈，此时应用层再记一遍，纯属冗余且浪费存储。上线前确认监控链路是否已覆盖。
