Java应用异常必须过滤重写，禁止直接返回Exception.toString()或堆栈；应统一拦截转换为业务错误码+模糊提示，日志需记录完整堆栈并脱敏敏感信息，第三方SDK异常须显式捕获、安全包装且保留cause链。
用户看到的异常信息必须过滤和重写
Java 应用直接把 Exception.toString() 或堆栈打印（e.printStackTrace()）返回给前端或界面，属于典型的安全漏洞。真实错误如数据库连接失败、文件路径不存在、SQL 语法错误，往往包含环境细节（/app/config/db.properties）、中间件版本（HikariCP-5.0.1）、甚至用户名字段名（user_pwd），这些都可能被用于进一步攻击。
正确做法是：所有抛到外层的异常必须经过统一拦截，转换为预定义的业务错误码 + 模糊化提示。例如：
try {
userService.updateProfile(user);
} catch (SQLException e) {
throw new BusinessException("E002", "用户信息保存失败，请稍后重试");
}
- 不暴露具体技术栈（避免说“MySQL 连接超时”）
- 不暴露路径、类名、方法名（禁止出现
com.example.dao.UserDao.save()） - 错误码
E002仅用于日志追踪，前端不可解析含义
日志中必须保留原始异常完整堆栈
用户看不到的错误详情，要确保能被运维和开发快速定位。关键不是“记不记”，而是“怎么记”。常见错误是只记录 e.getMessage()，导致丢失根因。
使用 SLF4J / Log4j 时，必须传入 Throwable 参数：
立即学习“Java免费学习笔记（深入）”；
logger.error("Failed to process payment for order {}", orderId, e);
- 上面这行会输出完整堆栈；而
logger.error("...{}", e)（把异常当参数）只会打印toString()，丢掉堆栈 - 敏感字段（如密码、token）需在日志脱敏：用
LogMasker工具类或 AOP 拦截器提前清理e.getStackTrace()中的敏感上下文 - 异步线程中抛出的异常容易丢失，务必用
Thread.setDefaultUncaughtExceptionHandler补漏
Spring Boot 的 @ControllerAdvice 处理边界要清晰
很多人以为加个 @ControllerAdvice 就万事大吉，但实际容易混淆三类异常的处理优先级：
-
BusinessException（自定义业务异常）→ 返回400+ 标准 JSON 错误体 -
IllegalArgumentException等运行时异常 → 视为客户端输入错误，也走400，但不记录 ERROR 级别日志 -
NullPointerException、SQLException等系统异常 → 返回500，强制记录 ERROR 日志，并触发告警
特别注意：@ResponseStatus 注解不能替代逻辑判断——它只改 HTTP 状态码，不控制响应体内容。真正要区分响应格式，得靠 @ExceptionHandler 方法里手动构造 ResponseEntity。
第三方 SDK 抛出的异常更要小心包装
调用微信支付 SDK 抛出的 WeChatPayException、调用阿里云 OSS 的 OSSException，这类异常自带详细报错字段（如 err_code: INVALID_REQUEST、request_id: xyz123），直接透出等于交出调试权限。
必须做两件事：
- 用
instanceof显式捕获，不依赖通用Exception捕获（否则可能吞掉本该 500 的严重错误） - 提取其中可安全暴露的字段（比如微信的
return_msg是面向商户的，可转成用户提示；但err_code_des含调试细节，必须丢弃） - 保留原始异常作为 cause，供日志链路追踪：用
new BusinessException("E007", "支付请求未完成", wechatEx)
最常被忽略的一点：SDK 异常可能带二进制响应体（如图片上传失败时返回的错误 HTML），不清理就序列化进日志，会导致 ELK 解析失败或磁盘暴涨。
