背景： 项目运行过程中会出现各种各样的问题，常见的有以下几种情况： 业务流程分析疏漏，对业务流程的反向操作、边界分析设计不充分 调用外部服务、调用外部系统出现的超时、错误、返回值与预期不符 外部资源连通性问题，db等服务器出现的网络抖动或宕机 无论是分析设计、开发、测试、线上都需要能够准确定位问题并制定解决方案。 目的： 规范化异常的处理过程，避免异常被吞和到处都在捕获异常的情况 准确的反馈异常信息，为定位问题提供依据 通用性异常全局处理，降低业务开发关注度 对异常情况进行预警，以便能够及时响应 一、异常规划 1. 业务类异常 造成业务流程不能正确执行的行为，常见的几种： 输入必填验证 业务状态约束校验 权限验证 调用外部服务返回数据不符合预期 这类异常需要给调用方返回明确的异常描述信息，一般情况下和代码无关，无需调整编码 注：是业务完整性的一部分，需提前分析 2. 系统类异常 服务调用异常： 超时、中断、接口异常（非200请求） 第三方异常 ：db\redis\消息队列 连接失败等 注：通常与业务流程无关，与第三方系统有关，不能简单的通过调整代码解决 3. 通用异常 编码不严谨、数据异常造成的问题，不可预测 举例：参数类型不匹配、空指针、数组越界 二、异常拦截 在springboot中全局异常拦截处理已知的有下面2种方案： 方案1：@ControllerAdvice、实现ErrorController 注：利用springboot自带的拦截机制，只需要定义出处理的策略，没有破坏springboot的约定 方案2：继承AbstractHandlerExceptionResolver，完全自定义处理策略 注：使用spring中最底层的类，打破了springboot的约定，能够拦截到所有异常 三、方案实践 笔者基于方案一进行实践。 1. 异常拦截时序图 2. RrcRestAdvice实现代码 2. RrcExpHandler实现代码 注意：基于RestControllerAdvice的异常拦截只能捕获请求达controller之后的程序异常，所以需要实现ErrorController处理之前的异常。 总结： 推荐基于springboot中@ControllerAdvice 和 ErrorController接口的约定，相对较符合springboot的约定。 其他可选方案： 继承AbstractHandlerExceptionResolver 优点：可完全自定义处理策略。缺点：对框架约定破坏较为严重，自定义处理策略容易疏漏。 继承HandlerInterceptorAdapter 理论上可以处理业务代码抛出的异常，优缺点没有进行过验证。 https://www.cnblogs.com/f-anything/p/10082637.html