Java异常脱敏核心是在日志记录、接口响应等输出环节拦截清洗敏感信息，而非仅捕获异常；推荐日志框架层（Logback/Log4j2）脱敏，辅以全局异常处理器轻量清洗、自定义异常类封装脱敏逻辑，并覆盖数据库、第三方SDK及控制台等易漏点。
Java 异常处理中对敏感信息脱敏后再输出，核心原则是：**不直接打印原始异常堆栈（尤其含用户输入、密码、密钥、手机号等），而是在日志或响应前对敏感内容做识别与替换**。关键不是“捕获异常后统一脱敏”，而是“在日志记录、接口返回、控制台输出等出口环节拦截并清洗”。
日志框架层脱敏（推荐）
使用 Logback 或 Log4j2 等主流日志框架，在 Appender 或 Layout 中嵌入脱敏逻辑，避免业务代码处处手动处理：
-
Logback 示例（自定义 PatternLayout）：继承
PatternLayout，重写doLayout()，用正则匹配并替换常见敏感字段（如"password=\S+"、"token=\S+"、"phone=\d{11}"），再返回脱敏后的字符串 -
Log4j2 示例（自定义 Lookup 或 ScriptAppender）：通过
${sys:xxx}或脚本插件，在日志格式化阶段调用脱敏工具类 - 注意：脱敏规则需兼顾性能，避免在正则中使用贪婪匹配或回溯爆炸；敏感词可配置化（如从 YAML 加载正则列表）
全局异常处理器中脱敏（Spring Boot 场景）
在 @ControllerAdvice + @ExceptionHandler 中统一处理 Web 层异常，对异常消息和堆栈做轻量清洗：
- 不要直接调用
e.toString()或Arrays.toString(e.getStackTrace()) - 提取异常消息（
e.getMessage()）后，用工具类（如 Apache Commons Text 的StringSubstitutor或自定义正则替换）过滤敏感内容 - 堆栈跟踪建议只记录到日志（经日志框架脱敏），接口响应体中仅返回简洁错误码和模糊提示（如
"操作失败，请稍后重试"），不暴露堆栈 - 示例：
message.replaceAll("(?i)password\s*=\s*['"\w]+", "password=***")
自定义异常类携带脱敏能力
对业务强相关的异常（如支付失败、登录校验异常），可封装带脱敏逻辑的异常类：
立即学习“Java免费学习笔记（深入）”；
- 继承
RuntimeException，构造时接收原始敏感参数，但重写getMessage()返回已脱敏版本 - 例如：
new AuthException("login failed for user=138****1234, pwd=123456")→getMessage()返回"login failed for user=138****1234, pwd=***" - 配合枚举错误码，让前端靠 code 判断类型，message 仅作辅助提示，不依赖其传递关键数据
警惕被忽略的脱敏点
以下位置容易遗漏，但同样可能泄露敏感信息：
-
数据库异常：JDBC 抛出的
SQLException消息里可能含 SQL 片段（如WHERE phone='13812345678'），需在 DAO 层 catch 后包装为脱敏异常 - 第三方 SDK 异常：调用微信/支付宝 SDK 出错时，其异常 message 可能含订单号、openId 等，需在 service 层统一拦截清洗
-
IDE 控制台调试输出：开发时
e.printStackTrace()会直连终端，建议用 SLF4J 日志替代，并确保本地日志配置启用脱敏 Layout
脱敏不是加一层 try-catch 就完事，而是要结合日志体系、异常传播链和输出渠道做分层防御。重点守住日志记录、接口响应、监控告警这三类出口，敏感字段该掩码的掩码、该删除的删除、该泛化的泛化。
