getMessage() 返回异常构造时传入的字符串消息体，不包含类名、堆栈或cause信息；若未传参则返回null，嵌套异常需手动调用getCause().getMessage()获取。
getMessage() 返回的是什么内容
getMessage() 是 Throwable 类的方法，所有异常（包括 Exception 和 Error）都继承自它。它返回的是异常构造时传入的字符串，**不包含异常类名、堆栈轨迹或 cause 信息**。
常见误区是以为它能拿到完整错误描述，其实它只负责“消息体”——比如 new IllegalArgumentException("file not found") 中的 "file not found"。
- 如果构造异常时没传参（如
new NullPointerException()），getMessage()返回null - 嵌套异常（
cause）的信息不会自动拼接进来，需手动调用getCause().getMessage() -
中文乱码通常不是
getMessage()的问题，而是日志框架或控制台编码不匹配导致的显示问题
getMessage() 和 getLocalizedMessage() 的区别
getLocalizedMessage() 默认行为和 getMessage() 完全一致，但设计初衷是支持本地化——子类可重写它来返回语言适配的提示（例如根据 Locale 返回中文/英文消息）。JDK 自带的大多数异常类并未重写该方法。
-
NullPointerException、IOException等标准异常：两者返回值相同 - 自定义异常若需国际化，应重写
getLocalizedMessage()，而不是依赖getMessage() - 日志记录时建议优先用
toString()或printStackTrace()输出完整上下文，而非仅靠getMessage()
安全读取异常消息的实用写法
直接调用 e.getMessage() 可能触发 NullPointerException（当消息为 null 时），尤其在日志拼接或前端透出场景中需防御性处理。
String msg = e.getMessage();
if (msg == null) {
msg = e.getClass().getSimpleName();
}
更稳妥的方式是使用 Objects.toString(e.getMessage(), e.getClass().getSimpleName())，避免空指针且逻辑清晰。
- 不要把
getMessage()结果直接返回给前端——可能泄露敏感路径、SQL 片段或内部结构 - 生产环境建议统一用
e.toString()记录原始日志，再用白名单策略提取用户可见字段 - Spring Boot 中可通过
@ControllerAdvice拦截异常，对不同异常类型返回定制化 message，而不是全局依赖getMessage()
为什么有时 getMessage() 看起来“没内容”
典型现象：捕获到 SQLException 或 HttpClientErrorException，调用 getMessage() 却返回空字符串或极简文本（如 "Bad Request"），而 printStackTrace() 显示大量细节。
- 这是由具体异常实现决定的——例如
RestClientException子类常把详细原因放在getCause()中，自身getMessage()仅保留 HTTP 状态码级别描述 -
SQLException的真正错误信息通常在getSQLState()、getErrorCode()或嵌套的getCause()里 - 调试时别只看
getMessage()，先检查e.getCause() != null，再递归获取深层消息
异常信息的完整性从来不由单一方法保证，getMessage() 只是入口之一，关键是要理解它在整个异常链中的位置。
