e.printStackTrace() 不该出现在生产代码里，因为它直接输出到 System.err，无法控制位置、格式、级别，绕过日志框架能力，且缺失请求ID等上下文，多线程下输出混乱，而 logger.error("msg", e) 才能正确记录完整堆栈并集成日志生态。
为什么 e.printStackTrace() 不该出现在生产代码里
它直接往 System.err 输出，无法控制输出位置、格式、级别，也绕过日志框架的异步、滚动、过滤等能力。更关键的是，它不带上下文（比如请求 ID、用户 ID），排查线上问题时等于盲人摸象。
- 本地调试时用没问题，但上线前必须删掉或替换成日志语句
- IDE 控制台能看到完整堆栈，但服务器上
System.err可能被重定向、截断，甚至丢进黑洞 - 多线程环境下，多个
e.printStackTrace()的输出会混在一起，分不清谁是谁的异常
用 SLF4J + Logback 打印完整堆栈的正确写法
SLF4J 的 logger.error(String, Throwable) 重载方法会自动把异常堆栈写入日志，且保留原始结构（缩进、换行都正常）。
- ✅ 正确：
logger.error("处理订单失败，orderID={}", orderId, e); - ❌ 错误：
logger.error("处理订单失败，orderID={}，异常：{}", orderId, e);—— 这样e.toString()被当字符串拼进去，堆栈就没了 - ⚠️ 注意：第二个参数必须是
Throwable类型，不能是e.getMessage()或e.getStackTrace() - Logback 默认配置下，堆栈会完整打印；若用了
%ex或%xEx格式化器，确保没加maxDepth限制
e.printStackTrace() 和 logger.error(..., e) 输出内容差异
表面看都是“堆栈”，但底层行为和可维护性差很远：
-
e.printStackTrace()固定输出到System.err，路径不可配，无法按包/类过滤 -
logger.error(..., e)遵循日志级别（ERROR）、appender（文件、Kafka、ELK）、MDC 上下文（如MDC.put("traceId", id)） - 某些异常（如
OutOfMemoryError）在printStackTrace()中可能被截断；而成熟日志框架会尝试完整捕获 - 性能上，
printStackTrace()是同步阻塞调用；SLF4J+异步 appender 可大幅降低异常记录对主流程的影响
想临时看堆栈又不想改日志配置？用 String.valueOf(e) 加 Arrays.toString(e.getStackTrace()) 是错的
别自己拼——既难读又漏信息（比如 cause chain、suppressed exceptions）。真要调试，优先用 IDE 断点 + 异常断点；非得打出来，就用标准日志方式，再临时调高日志级别。
立即学习“Java免费学习笔记（深入）”；
- ❌ 别写：
logger.debug("stack: " + Arrays.toString(e.getStackTrace()));—— 没有类名缩进，没有 cause，没有 line number 格式化 - ✅ 替代方案：在测试环境启用
logback.xml中的<turbofilter class="ch.qos.logback.classic.turbo.MarkerFilter">...</turbofilter>，或直接用logger.error("DEBUG ONLY", e);配合临时 ERROR 级别 - 最容易被忽略的一点：很多团队忘了在 catch 块里重新抛出异常时，要用
throw new XxxException("msg", e)保留 cause，否则链路就断了
