Java中安全的异常处理日志核心是不泄露敏感信息、不丢失关键上下文、不因日志引发新问题；需脱敏敏感字段、区分异常类型记录、用MDC注入traceId等上下文、禁用不安全日志配置。
Java 中安全的异常处理日志，核心是：不泄露敏感信息、不丢失关键上下文、不因日志本身引发新问题。重点不是“记下所有”，而是“记对东西”。
避免在日志中打印原始异常堆栈（尤其生产环境）
直接 logger.error("发生错误", e) 看似方便，但可能把数据库密码、用户令牌、内部路径、第三方密钥等敏感内容暴露在日志文件里——特别是当异常消息或堆栈中包含 toString() 泄露字段时。
建议做法：
- 用
e.getMessage()或自定义简洁错误码替代完整堆栈，例如：logger.error("订单创建失败[ERR-ORDER-001], 用户ID: {}", userId) - 仅在调试/开发环境才记录完整堆栈；生产环境如需定位，改用带唯一 traceId 的结构化日志 + 集中式追踪（如 SkyWalking、ELK + OpenTelemetry）
- 对敏感字段（如 password、token、idCard）做日志脱敏，可用 Apache Commons Text 的
StringEscapeUtils或自定义过滤器拦截日志事件
区分异常类型，按需记录不同粒度信息
不是所有异常都该被同等对待。业务异常（如余额不足）、系统异常（如空指针）、第三方调用异常（如 HTTP 503），日志策略应不同：
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 业务异常：通常不打 ERROR 级别，用 WARN 或 INFO，只记录可读提示 + 关键业务参数（如订单号、金额），不记录堆栈
- 系统异常（未捕获 RuntimeException）：必须记录堆栈，但先检查是否含敏感字段；建议全局统一异常处理器（@ControllerAdvice）集中处理并脱敏
- 第三方异常：记录对方服务名、请求 ID、HTTP 状态码、耗时；避免原样打印响应体（可能含 token 或用户数据）
使用 MDC（Mapped Diagnostic Context）增强上下文安全性
MDC 可以在线程级注入 traceId、userId、requestId 等，让每条日志自带身份标识，便于排查又不污染业务代码。
安全使用要点：
- 务必在请求入口（如 Filter 或 WebMvcConfigurer）中初始化 MDC，并在 finally 块或 try-with-resources 中
MDC.clear()，防止线程复用导致日志串号 - 禁止将明文密码、token 放入 MDC；如需用户标识，用脱敏后的 userId（如
user_****1234） - 配合 Logback 的
%X{traceId}或 Log4j2 的%X{traceId}在 pattern 中输出，无需手动拼接
日志框架与配置层面的安全加固
再好的代码逻辑，也依赖底层日志组件不“帮倒忙”：
- 禁用日志框架的 JNDI / LDAP 查找功能（Log4j 2.17+ 已默认关闭，但仍需确认无旧版本残留）
- 避免在日志格式化字符串中拼接不可信输入，例如
logger.info("用户 {} 登录", userInput)是安全的，但logger.info("用户 " + userInput + " 登录")可能触发恶意格式化（如%n换行攻击） - 设置日志文件权限为 640（属主读写，属组读，其他无权限），目录设为 750；避免日志写到 webroot 下被外部访问
- 启用日志轮转和大小限制，防止磁盘打满导致服务异常；敏感系统建议加密归档日志（如用 Logback 的
EncryptingOutputStream扩展）
不复杂但容易忽略：日志安全的本质，是把“谁、在什么上下文中、做了什么、结果如何”说清楚，而不是把 JVM 内部全吐出来。控制输出内容、隔离敏感数据、绑定可信上下文，三条做到位，就跨过了大多数安全红线。
