printStackTrace()有时只输出半截堆栈，因其默认仅输出最外层异常、不递归展开cause链，且在Android/Logcat或日志框架中易被重定向、缓冲未刷新或行级截断；需用StringWriter+PrintWriter捕获完整字符串并手动遍历cause链输出。
为什么 printStackTrace() 有时只输出半截堆栈？
直接调用 e.printStackTrace() 看似能打出完整堆栈，但实际常被截断——尤其在 Android、Logcat 或某些日志框架（如 Log4j、SLF4J）中，它默认输出到 System.err，而该流可能被重定向、缓冲未刷新，或被日志系统按行截断。更关键的是：如果异常是被包装过的（比如 InvocationTargetException、ExecutionException），printStackTrace() 默认只展开最外层，不会递归打印 cause 链。
怎样让 printStackTrace() 真正打全？
核心是两点：确保输出目标可捕获全部内容 + 主动展开嵌套异常。推荐做法：
- 用
e.printStackTrace(new java.io.PrintWriter(new java.io.StringWriter()))把堆栈写入内存字符串，再通过你信任的日志方法输出（如Log.e(tag, msg)或logger.error(msg)） - 若需递归展开所有 cause，别依赖默认行为；改用
Throwable.printStackTrace(PrintStream)的变体不支持递归，得手写遍历：for (Throwable t = e; t != null; t = t.getCause()) { t.printStackTrace(ps); } - 注意 JDK 版本差异：Java 7+ 的
printStackTrace()对Suppressed Exceptions（try-with-resources 中的）默认不显示，需显式调用getSuppressed()并逐个打印
printStackTrace() 在生产环境为什么不该直接用？
它绕过日志级别控制、无格式化能力、线程不安全（PrintStream 内部有同步但不可控）、且输出不可被集中收集或过滤。常见后果：
- 在 Spring Boot 中混用
printStackTrace()和logger.error("msg", e)，导致同一异常堆栈重复出现两次，且格式不一致 - Android 上
System.err输出可能被系统丢弃，或因缓冲延迟，在 crash 时根本没刷出 - 微服务中，原始堆栈不含 traceId，无法关联链路，排查时找不到上下文
替代方案：用日志框架的异常参数更可靠
所有主流日志框架都支持把 Throwable 作为最后一个参数传入，自动处理 cause 链和 suppressed 异常：
- SLF4J：
logger.error("DB query failed", e)—— 内部调用e.printStackTrace()的增强版，递归展开 cause - Log4j2：
logger.error("Timeout", e)—— 默认启用ExtendedStackTracePatternConverter，含类加载器、模块信息 - Android：
Log.getStackTraceString(e)返回完整字符串，再喂给Log.e()
真正容易被忽略的点：即使用了日志框架，如果异常对象本身是代理（如 Spring AOP 生成的 CGLIB 代理抛出的异常），堆栈里可能出现 $$EnhancerBySpringCGLIB$$ 这类干扰项——这时得结合 Thread.currentThread().getStackTrace() 辅助定位真实入口。
