应避免向用户暴露原始异常信息，因其常含类名、路径、SQL片段等敏感细节，易被攻击者利用；需在Controller层捕获并记录完整堆栈，响应仅返回预定义错误码和友好文案，统一用@ControllerAdvice处理，并按异常类型分级响应。
不应该直接暴露原始异常信息给用户，这是Java应用安全设计的基本要求。
为什么不能把Exception.getMessage()直接返回给前端
原始异常信息常包含内部实现细节：类名、方法名、文件路径、数据库表名、SQL片段、服务器环境（如java.version）、甚至临时文件路径。攻击者可据此构造针对性攻击，比如利用SQLException中的错误提示推测SQL注入点，或通过FileNotFoundException路径遍历尝试读取敏感配置文件。
- 常见风险示例：
java.io.FileNotFoundException: /app/config/db.properties (No such file or directory)暴露了部署结构 -
org.hibernate.exception.ConstraintViolationException: could not execute statement [ERROR: duplicate key value violates unique constraint "users_email_key"]泄露了表名和字段约束 -
开发环境默认开启的
Whitelabel Error Page会完整打印堆栈，生产环境必须禁用
如何安全地向用户返回错误提示
核心原则是“对内记录详情，对外返回泛化、无害、可理解的提示”。需分层处理：
- 在Controller层捕获异常，用
logger.error("业务操作失败", e)记录完整堆栈（含e参数），但响应体只返回预定义的错误码和用户友好的文案，例如{"code": "USER_LOGIN_FAILED", "message": "登录失败，请检查账号或密码"} - 避免在日志中记录敏感数据（如密码、身份证号），可用
logger.error("支付失败，订单ID: {}", orderId)代替logger.error("支付失败，订单ID: {}, 用户手机号: {}", orderId, phone) - 使用统一异常处理器（如
@ControllerAdvice+@ExceptionHandler），集中拦截RuntimeException、IOException等，避免每个接口重复写try-catch
哪些异常类型尤其需要警惕
以下几类异常若未处理，极易成为信息泄露入口：
立即学习“Java免费学习笔记（深入）”；
-
SQLException及其子类：默认getMessage()常含数据库方言、表/列名、索引名，应统一转为“系统繁忙，请稍后重试” -
NullPointerException、ArrayIndexOutOfBoundsException：说明代码存在逻辑缺陷，暴露给用户会降低信任，且可能被用于探测接口行为 - 自定义异常（如
UserNotFoundException）：不要在消息中拼接用户输入（如"用户 " + username + " 不存在"），防止XSS或用户名枚举；应固定文案+错误码 - 第三方SDK抛出的异常（如
OkHttpClient的SocketTimeoutException）：其getMessage()可能含目标域名、端口，需过滤
真正难的不是加一层try-catch，而是建立异常分类机制——区分“用户可操作的错误”（如参数校验失败）、“需人工介入的系统错误”（如数据库连接中断）、“不可恢复的致命错误”（如JVM OOM），每类对应不同的响应策略和日志级别。这点常被忽略，却直接影响问题定位效率和用户体验边界。
