应继承runtimeexception并定义带errorcode和context的异常基类， errorcode用枚举或常量，保留原始异常链，变量存context而非message，重写tostring以输出关键信息。
Java里异常信息不是靠“拼字符串”临时凑出来的，而是要通过自定义异常类把错误码、业务上下文、原始异常链一起固化进去——否则日志里全是 "null pointer" 或 "illegal argument"，根本看不出是“用户余额不足”还是“优惠券已过期”。
怎么让异常自带错误码和业务语义？
别再用 throw new RuntimeException("余额不足") 这种写法。它没法区分场景，前端也不能靠字符串匹配提示文案。正确做法是定义带 errorCode 字段的异常基类：
public abstract class BaseException extends RuntimeException {
private final String errorCode;
private final Map<String, Object> context = new HashMap<>();
protected BaseException(String errorCode, String message) {
super(message);
this.errorCode = errorCode;
}
protected BaseException(String errorCode, String message, Throwable cause) {
super(message, cause);
this.errorCode = errorCode;
}
public String getErrorCode() { return errorCode; }
public Map<String, Object> getContext() { return context; }
}
-
errorCode必须是枚举或常量（如USER_INSUFFICIENT_BALANCE），不能是硬编码字符串 - 构造时传入
cause，才能保留原始异常堆栈，避免丢失关键线索 - 用
context存订单号、用户ID等现场数据，排查时直接可查，不用翻日志找关联字段
该继承 Exception 还是 RuntimeException？
绝大多数业务异常必须继承 RuntimeException。受检异常（extends Exception）在分层调用中会强制上层加 throws，导致 Service 层、Controller 层到处都是异常声明，严重污染接口契约。
- 只有极少数场景适用受检异常：比如调用银行支付 SDK 时，必须确保调用方显式处理“签名失败”这类不可忽略的集成错误
- Spring 全局异常处理器（
@RestControllerAdvice）只捕获RuntimeException及其子类，继承Exception的异常会被绕过 - 如果误用受检异常，你会看到 Controller 返回 500，但全局异常处理器压根没触发——因为 Spring 默认不拦截受检异常
异常消息里能不能拼接变量？
可以，但禁止在 message 字段里直接拼接敏感或动态值（如密码、token、完整 SQL）。正确做法是把变量放进 context，消息保持静态可读：
立即学习“Java免费学习笔记（深入）”；
// ✅ 好：message 固定，变量走 context
throw new BusinessException("USER_LOGIN_FAILED", "登录失败")
.withContext("username", username)
.withContext("ip", request.getRemoteAddr());
// ❌ 坏：message 含变量，日志聚合失效、安全风险、i18n 难做
throw new BusinessException("USER_LOGIN_FAILED", "登录失败: 用户 " + username + " 从 " + ip + " 登录");
- 静态 message 方便 ELK 按模板聚合错误频次；动态拼接会导致每条日志 message 都不同，无法统计
-
context中的值可被日志框架自动脱敏（如屏蔽手机号中间四位），message 里的内容则无法控制 - 国际化时，message 是 key，变量由前端或 i18n 工具注入，而不是后端硬拼
最常被忽略的一点：异常类本身要实现 toString() 或重载日志输出逻辑，否则打印异常时看不到 errorCode 和 context ——它们就只是藏在对象深处的摆设。
