printStackTrace() 不该出现在生产代码里，因为它直接输出到 System.err，无法控制目标、格式、级别，也无法集成日志系统，导致日志归属不清、缺失上下文（如 traceId、用户ID），排查困难。

为什么 printStackTrace() 不该出现在生产代码里

它把堆栈直接输出到 System.err，无法控制输出目标、格式、级别，更没法集成进日志系统。一旦上线，你既找不到日志归属模块，也搜不到上下文字段（比如请求 ID、用户 ID），排查时只能靠猜。

• 用 logger.error("业务操作失败", e) 替代 e.printStackTrace()
• 确保日志框架（如 Logback / Log4j2）已配置异步 Appender 和合理的日志级别
• 避免在 catch 块里只写 logger.error(e.getMessage()) —— 这会丢掉堆栈，等同于“静默吞异常”

如何让异常日志自带关键上下文

单纯记录异常本身价值有限。真正有用的是：这个异常发生在哪个接口？由谁触发？处理的是哪条数据？

• 在捕获异常前，用 MDC（Mapped Diagnostic Context）注入上下文：MDC.put("traceId", request.getTraceId())
• 日志 pattern 中包含 MDC 字段，例如 Logback 的 %X{traceId}
• 构造异常消息时拼接业务标识：new ServiceException("订单创建失败，orderNo=" + orderNo, e)

try-with-resources 与异常抑制（suppressed exception）的坑

当 try 块和 close() 都抛异常时，JVM 会把 close() 异常设为 suppressed，并只抛出主异常——但默认日志不会打印 suppressed 部分，容易漏掉资源清理失败的根本原因。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 检查日志框架是否开启 suppressed 异常输出（Logback 1.4+ 默认开启；旧版需显式配置 %ex{full}）
• 调试时可用 e.getSuppressed() 手动检查，例如：

if (e.getSuppressed().length > 0) {
    logger.warn("存在被抑制的异常: {}", Arrays.toString(e.getSuppressed()));
}

自定义异常类要不要重写 toString() 或 getLocalizedMessage()

通常不用。日志框架调用的是 Throwable.toString()，它默认返回 getClass().getName() + ": " + getMessage()，已经够用。重写反而可能破坏标准行为，尤其在链路追踪或监控系统解析时。

立即学习“Java免费学习笔记（深入）”；

• 真正要做的，是在构造异常时传入有意义的 message，而非依赖重写方法“美化”输出
• 若需结构化信息（如错误码、HTTP 状态码），应作为字段暴露，例如 MyBusinessException.getErrorCode()，再由日志 Layout 单独提取
• 避免在 getMessage() 里拼接敏感信息（如密码、token），防止意外泄露到日志

异常日志不是越详细越好，而是要在可追溯性、安全性和性能之间做取舍。MDC 字段没清理干净、suppressed 异常被忽略、异常消息里硬编码敏感值——这些才是线上最常踩的暗坑。