Java中异常不是必须打印堆栈，但生产环境catch块应优先使用log.error("msg", e)输出完整堆栈；仅在明确预期、无调试价值且已妥善处理时（如超时重试、文件不存在创建默认配置）可省略。
Java中异常必须打印堆栈吗
不是必须，但绝大多数情况下应该——尤其在生产环境的 catch 块里只写 e.getMessage() 或直接吞掉异常，等于主动丢掉关键诊断信息。
log.error("xxx", e) 和 log.error("xxx" + e) 的区别
前者会完整输出异常类型、消息和堆栈；后者只拼接 e.toString()，丢失堆栈，等价于白屏调试。
-
log.error("DB query failed", e)→ 正确：SLF4J / Log4j 识别第二个参数为Throwable，自动渲染堆栈 -
log.error("DB query failed: " + e)→ 错误：字符串拼接后只剩NullPointerException: null这类无上下文提示 - Logback / Log4j2 中，只有形参为
Throwable的重载方法才触发堆栈打印
什么时候可以不打堆栈
仅限明确预期、无调试价值、且已充分处理的场景，比如网络超时重试、文件不存在时创建默认配置。
- 业务逻辑中主动抛出的自定义异常（如
BusinessException），若已通过返回码/状态封装，且上层统一拦截处理，catch中可不打印堆栈 - 使用
Optional.orElseThrow()或Objects.requireNonNull()触发的NullPointerException，属于防御性编程结果，堆栈意义有限 - 单元测试中
expected = XxxException.class场景，不需要手动捕获打印
日志级别与堆栈输出的配合
堆栈必须搭配 ERROR 或至少 WARN 级别，INFO 级别打堆栈是噪音，也违反日志分级原则。
立即学习“Java免费学习笔记（深入）”；
// ✅ 推荐：错误场景 + 堆栈 + 上下文
log.error("Failed to parse JSON for user {}, userId={}", username, userId, e);
// ❌ 避免：INFO 级别 + 堆栈（干扰监控、浪费磁盘）
log.info("JSON parse error", e); // 即使有 Throwable 参数，级别错了也没用
堆栈本身不解决异常，但它决定了你能否在凌晨三点快速定位是 Kafka 消费者线程卡死，还是数据库连接池耗尽。漏掉它，等于把问题藏进黑盒。
