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 部分，容易漏掉资源清理失败的根本原因。
- 检查日志框架是否开启 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()，已经够用。重写反而可能破坏标准行为，尤其在链路追踪或监控系统解析时。
- 真正要做的，是在构造异常时传入有意义的
message，而非依赖重写方法“美化”输出 - 若需结构化信息（如错误码、HTTP 状态码），应作为字段暴露，例如
MyBusinessException.getErrorCode()，再由日志 Layout 单独提取 - 避免在
getMessage()里拼接敏感信息（如密码、token），防止意外泄露到日志
