不推荐用 e.printStackTrace()，因其绕过日志系统，导致日志分散、无上下文、不可配置且有性能隐患；应使用 logger.error("描述", e) 正确输出带堆栈的结构化日志。
直接调用 e.printStackTrace() 不推荐用于生产环境，它默认输出到 System.err，无法控制日志级别、目标（如文件、远程服务）、格式和归档策略；而 logger.error(...) 是规范做法，能统一接入日志框架（如 Logback、Log4j2），支持结构化、可检索、可监控。
为什么不要用 e.printStackTrace()
它绕过日志系统，导致：
- 日志分散：错误信息混在控制台，无法集中收集（如 ELK、Sentry）
- 无上下文：缺少时间戳、线程名、类名、请求 ID 等关键字段
- 不可配置：不能按环境关闭/降级，也不能动态调整输出深度或脱敏
- 性能隐患：频繁调用可能触发同步 I/O，阻塞主线程（尤其在高并发场景）
正确使用 logger.error 记录异常堆栈
主流日志框架（SLF4J + Logback / Log4j2）都支持直接传入 Throwable 参数，自动打印完整堆栈，且保留原始异常链（cause chain）：
try {
// 可能抛异常的代码
} catch (IOException e) {
logger.error("文件读取失败，路径: {}", filePath, e); // ✅ 推荐：异常对象作为最后一个参数
}
注意：必须把异常对象 e 作为方法的最后一个参数传递，否则日志框架不会识别为“带堆栈的错误”，只会输出字符串，丢失堆栈信息。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
避免常见错误写法
以下方式都会丢失堆栈或降低可维护性：
-
logger.error("读取失败: " + e);→ 调用e.toString()，无堆栈 -
logger.error("读取失败", e.getMessage());→ 把消息当异常对象传，堆栈不打印 -
logger.error("读取失败", e);→ ✅ 正确，但建议加描述性前缀，便于搜索 -
e.printStackTrace(); logger.error("手动捕获异常");→ 重复输出，且printStackTrace仍污染标准错误流
进阶建议：增强可追溯性
在 error 日志中补充业务上下文，提升排查效率：
- 记录关键变量值（如 ID、URL、用户 ID），但注意脱敏敏感信息
- 结合 MDC（Mapped Diagnostic Context）注入请求唯一标识：
MDC.put("traceId", UUID.randomUUID().toString());，确保整条链路日志可关联 - 对特定异常类型做分类处理（如网络超时 vs 数据库约束冲突），用不同日志级别或标签区分
- 避免在循环内高频打 error 日志，可聚合后统一上报，或加限流（如每分钟最多 5 条同类错误）
