Java异常处理防敏感信息泄露的核心是：不将手机号、密码、SQL等敏感内容写入异常消息，不在响应中暴露原始堆栈，而是通过统一拦截、日志脱敏、自定义异常封装和第三方异常剥离四环节系统设防。
Java异常处理中避免敏感信息泄漏到堆栈，核心是“不把不该出现的内容塞进异常消息，也不让原始堆栈直接暴露给外部”。重点不在堆栈本身能否隐藏（它天然包含调用链），而在于控制哪些信息进入异常构造过程、谁能看到完整堆栈、以及堆栈是否被不当传播。
构造异常时剥离敏感内容
异常的 getMessage() 和堆栈起始行往往来自你主动传入的字符串。一旦把手机号、密码、SQL语句、文件路径拼进去，就等于把敏感数据固化在异常对象里，后续无论怎么包装都难彻底清除。
- 不要写：
throw new ServiceException("用户 138****1234 登录失败: " + e.getMessage()) - 应该写：
throw new ServiceException("登录失败，请检查账号信息")，并在内部日志中单独记录脱敏后的上下文 - 对可能混入敏感字段的业务参数（如 request、user、order），先做掩码再用于日志，绝不直接 toString() 后塞进异常消息
统一拦截并重写对外输出
即使底层抛出了带敏感词的异常，也不代表前端或调用方必须看到它。Spring 的 @ControllerAdvice 或 WebMvcConfigurer 可以在出口处统一拦截、转换、过滤。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 捕获所有 Exception，只返回通用错误码和模糊提示，例如
"操作失败，请稍后重试" - 对不同异常类型分层响应：AuthenticationException → 401/400；SQLException → 500 并触发告警，但响应体不提数据库或表名
- 禁用 ResponseEntity.status(500).body(e.getMessage()) 这类直接透出原始消息的做法
日志中切断敏感信息与堆栈的绑定
很多泄露其实发生在 log.error("xxx", e) 这一步——你以为只打了堆栈，但 SLF4J 默认会把异常的 getMessage() 拼在第一行，而那行很可能含身份证或 token。
立即学习“Java免费学习笔记（深入）”；
- 确保日志框架配置了
%ex或%xEx占位符单独输出堆栈，避免和 message 行耦合 - 在记录前对日志事件做预处理：用 MDC 注入 traceId，并用自定义 Appender 对 message 字段执行正则脱敏（如屏蔽 11 位数字+星号组合）
- 禁止在 debug/info 级别打印完整异常，error 级别也只在受控环境（如内网 ELK）保留全量堆栈
包装第三方异常时清除上下文
调用 SDK、HTTP 客户端、数据库驱动时，它们抛出的异常常自带请求 URL、Header、SQL、响应体等。直接 throw new BusinessException("调用失败", e) 会把整个原始异常链带上，敏感信息随之泄露。
- 使用 ExceptionUtils.getRootCause(e) 获取最内层异常，判断类型后再决定是否包装
- 对已知高风险异常（如 FeignException、JDBC SQLException），提取错误码和通用原因，丢弃原始 message
- 必要时调用
e.fillInStackTrace()清除无关调用帧，或创建新异常时不传 cause（仅限明确无需追踪的场景）
