Exception.getMessage() 返回异常构造时传入的简短字符串说明，不包含堆栈等上下文；对底层异常可能为null或空，需判空处理，且不可直接透传前端以防敏感信息泄露、术语外泄等问题。
Exception.getMessage 返回的是什么内容
Exception.getMessage() 返回的是异常构造时传入的字符串，通常是开发者手动指定的简短说明。它不包含堆栈、类名、行号等上下文信息，只负责“一句话讲清问题”。比如 new IllegalArgumentException("用户ID不能为空") 抛出后，getMessage() 就是 "用户ID不能为空"。
但要注意：很多底层异常（如 NullPointerException、SQLException）默认构造时不传参，此时 getMessage() 可能返回 null 或空字符串——直接用它做前端提示会出空白或 NPE。
为什么不能直接把 getMessage() 透传给前端
直接暴露原始 getMessage() 容易引发安全与体验问题：
- 敏感信息泄露：数据库驱动抛出的
SQLException可能含表名、字段名甚至 SQL 片段 - 开发术语外泄：如
"No qualifying bean of type 'UserService' available"对前端用户毫无意义 - 国际化缺失：硬编码英文消息无法适配多语言前端
- 格式不可控：部分异常消息带换行符或控制字符，前端渲染可能错乱
推荐的封装方式：统一异常处理器 + 白名单过滤
在 Spring Boot 中，建议用 @ControllerAdvice + @ExceptionHandler 拦截并转换异常：
```java
@ExceptionHandler(Exception.class)
public ResponseEntity<apiresponse> handleException(Exception e) {
String msg = e.getMessage();
if (msg == null || msg.trim().isEmpty()) {
msg = "系统繁忙，请稍后再试";
}
// 白名单校验：只允许已知业务异常的消息透出
if (e instanceof BusinessException || e instanceof ValidationException) {
return ResponseEntity.badRequest().body(ApiResponse.error(msg));
}
// 其他异常一律降级为通用提示（日志里保留完整异常）
log.warn("Unexpected error", e);
return ResponseEntity.status(500).body(ApiResponse.error("操作失败，请重试"));
}
```</apiresponse>
关键点：
- 永远先判空
e.getMessage()，避免 NPE - 对非业务异常（如
NullPointerException）绝不返回原始getMessage() - 业务异常类（如自定义
BusinessException）可允许透出，但需确保构造时传入的是前端友好的中文短语 - 所有异常都必须打全量日志（用
e而非e.getMessage()），方便排查
前端拿到消息后还要注意什么
后端返回的提示消息只是起点，前端仍需做防御性处理：
- 始终检查响应体中 message 字段是否存在且为非空字符串，再渲染
- 避免直接 innerHTML 渲染，防止 XSS（尤其当后端未严格过滤时）
- 对超长消息做截断或折叠，比如限制在 60 字以内，超出显示“…”并提供点击查看详情入口
- 网络错误、超时等非 5xx/4xx 状态码场景，不要依赖后端 message，前端应有兜底文案
最常被忽略的一点：异常消息不是调试依据。哪怕你把 getMessage() 封装得再干净，也别让它承担定位根因的任务——日志、监控、traceId 才是真正该投入精力的地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
