应继承 RuntimeException 以实现非强制捕获的业务异常；需声明 private final int errorCode 并在构造时赋值；建议保留 fillInStackTrace 默认行为，除非性能敏感且错误码已足够定位问题；Spring 中需用 @RestControllerAdvice + @ExceptionHandler 显式配置全局捕获。
为什么继承 RuntimeException 而不是 Exception
因为你要的是「不强制捕获」的异常，比如参数校验失败、业务规则违反这类程序运行中可预期但不该被层层 try-catch 的问题。RuntimeException 及其子类属于 unchecked exception，调用方无需声明或处理，代码更干净；而继承 Exception 会逼迫所有上层方法加 throws 或包在 try 里，实际开发中几乎没人这么干——除非你真想强制调用方处理（比如 IO 异常），但错误码场景基本不需要。
常见错误现象：javac 报错 “unreported exception XxxException; must be caught or declared to be thrown”，就是不小心继承了 Exception 却没处理它。
- 确认父类是
RuntimeException，不是Exception或Throwable - 别在构造函数里漏掉
super(message)或super(message, cause)，否则堆栈跟踪会丢根因 - IDE 自动生成构造函数时注意删掉无参构造（除非你明确需要），避免误用
如何添加错误码字段并保证不可变
错误码本质是业务标识，必须稳定、不可变、能直接映射到文档或配置。用 final int 是最简单可靠的方式，别用 String 编码（难比对）、也别用静态常量池（耦合重、难扩展）。
使用场景：统一异常处理器（如 Spring 的 @ControllerAdvice）根据 errorCode 返回不同 HTTP 状态码或响应体；前端根据码值做差异化提示。
立即学习“Java免费学习笔记（深入）”；
- 字段声明为
private final int errorCode，只在构造时赋值 - 提供 getter 方法
getErrorCode()，不要 setter - 构造函数必须接收
errorCode，且优先级高于 message：先定码，再定提示 - 示例：
public class BizException extends RuntimeException {<br> private final int errorCode;<br> public BizException(int errorCode, String message) {<br> super(message);<br> this.errorCode = errorCode;<br> }<br> public int getErrorCode() { return errorCode; }<br>}
要不要重写 fillInStackTrace
要，但只在确定不需要完整堆栈时才关。默认行为会收集从抛出点到当前的全部栈帧，对日志友好，但有性能开销（尤其高频校验场景）。关闭后异常对象创建快 3–5 倍，但排查问题时看不到“谁调的谁”。
容易踩的坑：盲目重写成 return this 导致所有同类异常堆栈都一样，根本分不清触发路径。
- 如果错误码已足够定位问题（比如
USER_NOT_FOUND(1001)对应固定接口），且性能敏感，可关闭：@Override<br>public synchronized Throwable fillInStackTrace() {<br> return this;<br>} - 否则保留默认行为——大多数内部服务没必要动它
- 别只重写部分构造函数，所有构造入口都要一致处理，否则行为不统一
Spring 中怎么让自定义异常被全局捕获
Spring 不会自动识别你的 BizException，得靠 @ExceptionHandler 或 @RestControllerAdvice 显式绑定。它和异常类本身无关，纯属框架配置。
常见错误现象：抛了 BizException，但返回的是默认 500 页面或空 JSON，没走你的异常处理器。
- 确保异常处理器类加了
@RestControllerAdvice注解 - 方法上用
@ExceptionHandler(BizException.class)明确指定类型 - 检查包扫描范围：该处理器类是否在 Spring Boot 主类同包或子包下？否则不会被加载
- 如果用了多个 Advice，注意
@Order优先级，避免被更宽泛的Exception.class拦截器吃掉
复杂点在于：错误码要透传给前端，但又不能暴露内部细节。通常做法是在统一响应体里塞 code 字段，而不是直接把异常 message 当响应内容返回——message 是给人看的调试信息，code 才是机器可解析的契约。这点很容易被忽略，结果上线后前端靠字符串匹配做逻辑，一改提示就崩。
