标准异常类不适合传递业务上下文，因其无预留字段存请求ID、用户ID等信息；拼接至message会导致日志解析困难、结构化采集失败且无法安全提取参数。
为什么标准异常类不适合传递业务上下文
Java内置的异常如 IllegalArgumentException 或 RuntimeException 没有预留字段存请求ID、用户ID、操作路径等业务信息。直接拼接字符串到 message 里，会导致日志解析困难、结构化采集失败，且无法在捕获后安全提取原始参数。
如何设计可携带上下文的自定义异常类
继承 RuntimeException（或 Exception，视是否强制处理而定），添加只读字段并重写 toString() 或提供专用 getter。关键点：
- 所有上下文字段声明为
final，避免被子类篡改 - 不依赖
message存结构化数据；message仅作人类可读摘要 - 构造函数应支持「纯消息 + 上下文」和「带 cause 的重载」
- 避免在异常中持有大对象（如完整 request body），防止内存泄漏
示例：
public class OrderProcessingException extends RuntimeException {
private final String orderId;
private final String userId;
private final String traceId;
public OrderProcessingException(String orderId, String userId, String traceId, String message) {
super(message);
this.orderId = orderId;
this.userId = userId;
this.traceId = traceId;
}
// 可选：提供 cause 版本
public OrderProcessingException(String orderId, String userId, String traceId, String message, Throwable cause) {
super(message, cause);
this.orderId = orderId;
this.userId = userId;
this.traceId = traceId;
}
// 提供结构化访问
public String getOrderId() { return orderId; }
public String getUserId() { return userId; }
public String getTraceId() { return traceId; }
}
在日志和监控中真正用上这些字段
光定义字段没用，得让它们出现在日志输出和链路追踪里：
- SLF4J 日志中不要只写
log.error("failed", e)，而要用 MDC 注入关键字段：MDC.put("orderId", e.getOrderId()) - 全局异常处理器（如 Spring 的
@ControllerAdvice）中，应显式提取上下文字段，组装成结构化错误响应体 - 若用 OpenTelemetry，可在异常被捕获时调用
tracer.getCurrentSpan().setAttribute("exception.order_id", e.getOrderId()) - 避免在
toString()中拼接敏感字段（如身份证号、token），生产环境需脱敏
别踩：序列化、框架代理与泛型擦除的坑
自定义异常在分布式或 RPC 场景下容易出问题：
立即学习“Java免费学习笔记（深入）”；
- 如果异常要跨 JVM 传输（如 Dubbo、Feign），必须实现
Serializable，且所有字段类型也得可序列化 —— 别把HttpServletRequest塞进异常字段 - Spring AOP 代理可能包装异常，导致你 catch 的不是原始类型，建议用
ThrowableUtils.unwrap(throwable, YourException.class)安全提取 - 泛型异常（如
ApiException）在运行时会被擦除，无法靠instanceof判断类型，改用字段标识或枚举码更可靠
上下文字段的价值不在定义那一刻，而在它被下游系统稳定识别和消费的那一瞬间。多数人卡在“写了字段但没人读”，而不是“怎么定义字段”。
