关键在于“定义得对”而非“少定义”：仅当需差异化处理、携带特定语义、跨模块传递上下文或含结构化字段时才自定义异常；其余复用标准异常。
避免项目中异常类泛滥，关键不是“少定义”，而是“定义得对”——只在真正需要差异化处理、携带特定语义或需跨模块传递上下文时才自定义异常；其余情况直接复用标准异常或简单包装。
明确自定义异常的必要条件
以下情况才建议新建异常类：
- 业务场景有明确且不可被其他异常覆盖的语义（如
InsufficientBalanceException比IllegalArgumentException更能表达资金不足的业务含义） - 需要在 catch 块中被精确识别并执行特定恢复逻辑（例如重试、降级、告警分类）
- 必须携带额外结构化字段（如错误码、traceId、原始请求参数），且这些信息无法通过异常消息或嵌套异常合理传递
- 被多个子模块依赖，且各模块对同一错误的响应策略不同（如支付模块抛出，风控模块需拦截，日志模块需脱敏记录）
优先用组合替代继承，控制类数量
不必为每个业务错误码都建一个类。可设计通用基类 + 枚举驱动：
- 定义一个
BusinessException，包含errorCode、errorMessage、details字段 - 用枚举统一管理所有业务错误（如
ErrorCode.INSUFFICIENT_BALANCE），含默认提示、HTTP 状态码、是否可重试等元信息 - 抛出时只需
throw new BusinessException(ErrorCode.INSUFFICIENT_BALANCE, "余额不足") - 捕获方可通过
exception.getErrorCode()分支处理，无需 import 大量异常类
建立异常治理规范并落地检查
靠人自觉容易回退，需机制保障：
- 在代码评审清单中加入“新增异常类是否满足必要条件”条目，要求 PR 描述清楚使用场景和不可替代性
- 用 SonarQube 或自定义 Checkstyle 规则限制异常类命名空间（如只允许在
exception包下，且禁止出现XXXException2、TempException等模糊命名） - 定期扫描项目中所有
*Exception.java文件，统计继承链深度、空实现类、仅用于 throw new XXXException() 无任何额外字段/方法的类，标记待清理
把“不定义”变成一种显式决策
当遇到新错误场景，先问自己三个问题：
- 这个错误能否用
IllegalArgumentException、IllegalStateException、RuntimeException精准表达？ - 下游调用方是否真的需要根据这个异常类型做不同处理？还是只打印日志或返回固定错误码？
- 如果今天不定义它，半年后加监控、写单元测试、做灰度分流时会不会卡住？
多数时候答案是否定的。留白比堆砌更需要判断力。
