getMessage() 返回异常构造时传入的消息字符串（可能为null），toString() 返回“类名: 消息”，含类型信息但消息为null时显示“: null”。
getMessage() 返回什么，和 toString() 有什么区别
getMessage() 只返回异常的“消息字符串”，即构造异常时传入的 String 参数（或默认空字符串）。它不包含类名、堆栈线索，也不保证非 null——比如 NullPointerException 在无参构造时调用 getMessage() 就返回 null。
toString() 则返回 getClass().getName() + ": " + getMessage()，更完整但仍有局限：如果 getMessage() 是 null，结果里会显示 ": null"，容易误判。
- 想快速看错误原因（如日志摘要），优先用
getMessage()，但务必判空：String msg = e.getMessage();<br>log.warn("操作失败: {}", msg != null ? msg : "无详细信息"); - 调试阶段想一眼定位异常类型+消息，直接打印
e.toString()更省事 - 永远不要依赖
getMessage().length() > 0来判断是否有有效信息——有些异常（如SecurityException子类）可能合法地传入空字符串
为什么有时 getMessage() 返回 null，该怎么安全获取描述
Java 规范允许异常类在构造时不设置消息，尤其底层系统异常（如 NullPointerException、ArrayIndexOutOfBoundsException）常走无参构造。此时 getMessage() 必然为 null。
- 最稳妥的方式是 fallback 到
e.toString()：String desc = e.getMessage() != null ? e.getMessage() : e.toString();
- 若需统一格式且避免类名干扰，可用
Optional.ofNullable(e.getMessage()).orElseGet(e::toString) - 注意：
getCause()的getMessage()同样可能为null，链式异常需逐层检查
Throwable.getLocalizedMessage() 是不是更好用
getLocalizedMessage() 本意是返回本地化消息，但**绝大多数 JDK 内置异常并未重写它**，默认行为就是直接返回 getMessage()。自定义异常若没显式覆盖，两者完全等价。
- 除非你控制了所有异常类并做了国际化资源绑定，否则别指望
getLocalizedMessage()自动变中文或带上下文 - Spring 等框架的异常包装（如
HttpRequestMethodNotSupportedException）可能重写了它，但属于特例，不能泛化 - 线上日志中混用
getLocalizedMessage()和getMessage()会导致排查时语义不一致，建议团队统一用getMessage()+ 判空
日志记录时该不该只打 getMessage()
只记录 getMessage() 是常见但危险的习惯——它丢掉了异常类型和发生位置，线上问题几乎无法定位。
- 生产环境必须至少记录
e.toString()或完整堆栈（e.printStackTrace()输出到日志器） - 如果日志系统支持结构化字段（如 Logback 的
%ex），直接用框架提供的异常渲染，它会自动处理 null 消息和嵌套异常 - 做用户提示时才考虑仅用
getMessage()（并兜底），例如：String userMsg = Optional.ofNullable(e.getMessage())<br> .filter(s -> !s.trim().isEmpty())<br> .orElse("操作未成功，请稍后重试");
实际中最容易被忽略的是：异常消息本身可能是动态拼接的（比如 SQL 异常含敏感参数），直接打日志可能泄露数据；而 getMessage() 为 null 时不做 fallback，会让告警日志变成空行，排查时第一眼就错过。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
