异常消息必须包含可定位的上下文，如订单ID、用户ID、接口路径等业务标识，并用具体动作和值替代模糊动词，避免拼接敏感信息、运行时调用易错方法或在getMessage()中塞入堆栈。
异常消息必须包含「可定位的上下文」
Java里抛出的异常如果只写 "Error occurred" 这类泛化信息，排查时根本无法判断是哪个请求、哪条数据、哪个参数出了问题。关键不是“报错了”，而是“在哪错、因何错、谁触发的”。
- 务必包含业务标识：如订单ID、用户ID、接口路径 —— 例如
"Failed to process order #ORD-2024-7890: payment amount is negative" - 避免模糊动词：“failed”“invalid”要替换成具体动作和值：
"parseDate('2024-13-01') failed: month must be 1–12" - 不拼接敏感信息（如明文密码、身份证号），但可保留脱敏后的标识符：
"user_id=usr_8a2b...f3e1"
不要在异常消息里做逻辑判断或格式化
异常构造阶段不该调用可能失败的方法，比如 new IllegalArgumentException("User " + user.getName() + " not found") 中，若 user.getName() 抛空指针，原始错误就被掩盖了。
- 所有变量值应在抛出前确认非空/有效，或用
Objects.toString(user, "null")安全转换 - 避免在消息中调用
JSON.stringify()、LocalDateTime.now().toString()等易出错或带副作用的操作 - 时间戳、ID等应直接传入已计算好的字符串，而非在异常构造器里现场生成
区分 getMessage() 和日志记录内容
异常消息面向开发者调试，日志行面向运维监控，二者职责不同。很多团队把完整堆栈塞进 getMessage()，导致日志重复且难以结构化解析。
-
getMessage()只保留「一句话因果」：如"Cannot update status from 'PAID' to 'CANCELLED'" - 详细上下文（参数快照、SQL语句、HTTP头）应通过日志框架单独记录，例如 SLF4J 的
logger.error("Update status rejected", e) - 若需传递结构化数据给上层处理（如API返回码），应使用自定义异常字段，而非塞进字符串消息
自定义异常类要重写 toString() 吗？
一般不用。JDK 默认的 toString() 已包含类名 + 消息 + 堆栈缩略，够用。强行重写反而破坏标准行为，让 printStackTrace() 或 APM 工具解析异常时丢失关键信息。
立即学习“Java免费学习笔记（深入）”；
- 例外情况：仅当需要在控制台快速显示业务摘要（如运维脚本），且明确知道不会被日志框架捕获时，才考虑重写
- 更稳妥的做法是提供一个
toSummary()辅助方法，由调用方按需调用 - 切勿在
toString()中抛异常、访问数据库或远程服务 —— 这会导致printStackTrace()自身崩溃
public class OrderStatusTransitionException extends RuntimeException {
private final String orderId;
private final String fromStatus;
private final String toStatus;
public OrderStatusTransitionException(String orderId, String from, String to) {
super(String.format("Cannot transition order %s from '%s' to '%s'", orderId, from, to));
this.orderId = orderId;
this.fromStatus = from;
this.toStatus = to;
}
// 不重写 toString()，保持默认行为
public String toSummary() {
return String.format("[OrderStatus] %s: %s → %s", orderId, fromStatus, toStatus);
}
}
异常消息最常被忽略的一点：它不是给人“读得顺”的，而是给机器和人一起“查得准”的。多一个订单号，少一次grep；少一次运行时拼接，多一分堆栈可信度。 
