清理冗余自定义异常类需遵循“识别→评估→移除→验证”四步闭环：先通过名称、code、继承关系和使用痕迹识别冗余；再评估语义是否被替代；然后优先合并而非删除，辅以@Deprecated引导迁移；最后通过测试、日志、代码扫描和文档更新完成验证。
清理无用或重复定义的自定义异常类，核心是“识别→评估→移除→验证”四步闭环，重点不在删代码，而在保障异常语义不丢失、调用链不断裂。
识别冗余异常类
先定位哪些异常类可能冗余：
- 名称相似、code值重叠（如BusinessException和BizException都用1001表示参数校验失败）
- 继承关系混乱（多个异常类都直接继承RuntimeException，但实际只有一处抛出，其余从未被catch或日志记录）
- 仅含默认构造器、无业务字段（比如只有super(message)，没扩展code、timestamp等上下文）
- 在IDE中右键→“Find Usages”，结果为零，或仅出现在测试类/已注释掉的旧模块中
评估是否真可删除
不能只看“没人用”，得看它承载的语义是否已被替代：
- 检查全局异常处理器（如@ControllerAdvice）是否针对该异常做了特殊响应逻辑（如返回特定HTTP状态码、封装固定错误结构）
- 查看API文档或Swagger注解，确认该异常是否作为公开接口的@ApiResponses声明项
- 比对异常code字段：若两个异常类的code相同且message模板一致，说明语义重复，留一个即可
- 留意子类化场景——如果A异常是B异常的父类，而B只在某模块使用，A却被全局捕获，那删B可能没问题，删A则危险
安全移除与合并策略
删之前，优先考虑合并而非硬删：
立即学习“Java免费学习笔记（深入）”；
- 把功能重叠的异常类统一归并到一个标准类（如统一用AppException），通过code区分业务域（1001-用户模块，2001-订单模块）
- 保留原异常类但标记为@Deprecated，并在构造器里打印warn日志，引导调用方迁移
- 若必须删除，先全局替换throw new OldException(...)为新异常，并更新所有catch块，避免编译失败
- 配套修改统一异常处理器中的@ExceptionHandler方法签名，移除对应参数类型
验证与收尾
清理后必须验证是否影响真实行为：
- 跑一遍集成测试，尤其关注异常路径（如模拟参数校验失败、数据库超时等），确认返回的错误码、消息体、HTTP状态码符合预期
- 检查日志系统，确认错误日志中不再出现已删除异常类的全限定名
- 扫描DTO或VO类中是否残留对该异常类的引用（比如字段类型为OldException，这属于设计缺陷需一并修正）
- 更新团队Wiki或异常码文档，标注已下线的code范围及替代方案
