异常不能当单例用，因其构造时捕获的堆栈快照会定格在初始化时刻，导致后续抛出时堆栈错位、根源丢失；应改用每次新建的工厂方法。
这个问题本质是“把异常对象当单例用”，看似小操作，实则会严重破坏异常传播链和调试线索。异常对象本应是一次性、带上下文快照的瞬态实例，若被缓存复用或强制做成单例，会导致堆栈信息错位、根源丢失、甚至掩盖真实触发点。
为什么异常不能当单例用
异常对象（如 IllegalArgumentException、IllegalStateException）在构造时会自动捕获当前线程的堆栈快照（fillInStackTrace()）。一旦你把它声明为 static final 或注入为 Spring singleton bean，这个堆栈就永远定格在类加载或容器启动那一刻——后续所有抛出，都复用同一份过期堆栈，完全无法反映真实出错位置。
- 比如：
private static final RuntimeException BAD_REQUEST = new IllegalArgumentException("参数非法");，之后 anywhere 写throw BAD_REQUEST;，堆栈永远指向这行声明，而非实际调用处 - Spring 中若将自定义异常类声明为
@Component并设为 singleton scope，同样会复用同一个实例，getCause()和getStackTrace()都失去时效性
如何快速识别这类误用
观察异常日志中最可疑的三个信号：
-
堆栈第一行总指向某个静态字段初始化或配置类（如
Config.class:42、ExceptionHolder.java:15），而不是业务方法 - 多个不同业务场景抛出的同类异常，堆栈完全一致（连行号、方法名都一样）
-
异常消息正确，但
getCause()为 null，且getStackTrace().length == 0或极短（说明fillInStackTrace()被跳过或重置）
修复方式：用工厂方法替代静态实例
真正需要复用的是“创建逻辑”，不是异常对象本身。推荐以下安全写法：
- 定义静态工厂方法：
static IllegalArgumentException badRequest(String detail) { return new IllegalArgumentException("参数错误: " + detail); } - 使用时：
throw badRequest("user_id 为空");—— 每次都新建，堆栈精准 - 如需统一错误码，可封装为枚举驱动的工厂：
ErrorType.VALIDATION.error("邮箱格式不合法")，内部仍每次 new 异常
额外注意：避免代理/包装导致的堆栈截断
某些框架（如 Feign、Dubbo）或 AOP 切面会在抛出前对异常做包装（如 new RuntimeException(e)），若包装逻辑里没调用 e.fillInStackTrace()，也会丢失原始堆栈。检查类似代码：
- 是否用了
new RuntimeException(cause)而非new RuntimeException(msg, cause)？后者会保留 cause 堆栈 - 自定义异常类是否重写了
fillInStackTrace()并返回this？错误实现会清空堆栈 - 日志打印时是否只输出
e.toString()而忽略e.printStackTrace()或log.error("", e)？前者不显示堆栈
