1.1 什么是全局异常处理
想象一下你正在开发一个电商应用。用户下单时可能遇到库存不足、支付失败、网络超时等各种问题。如果没有全局异常处理，每个接口都需要重复编写try-catch代码块，就像每个房间都要单独准备灭火器一样繁琐。
全局异常处理实际上是一种设计模式。它允许我们在应用的某个中心位置捕获和处理所有异常，而不是在每个方法中分散处理。这就像给整个大楼安装了中央消防系统，任何地方发生火情都会自动触发统一的报警和处理机制。
我记得刚开始接触SpringBoot时，总在每个Controller方法里写满异常处理代码。后来发现全局异常处理能让代码变得清爽很多，维护起来也轻松不少。
1.2 全局异常处理的重要性
代码整洁度提升是最直观的好处。去掉那些重复的异常处理代码后，业务逻辑变得更加清晰可读。开发者可以专注于核心业务实现，而不必被各种异常处理细节分散注意力。
用户体验的一致性同样重要。想象用户在不同接口遇到异常时，如果每个接口返回的格式都不一样，那种体验肯定很糟糕。全局异常处理确保所有异常都以统一格式返回给前端，包括错误码、错误信息和时间戳等标准字段。
维护效率的提高也很明显。当需要修改异常处理逻辑时，只需要在一个地方调整，而不是在整个项目中搜索所有相关的异常处理代码。这个设计确实非常实用，大大减少了维护成本。
1.3 SpringBoot异常处理机制简介
SpringBoot在异常处理方面做了很多自动化配置。它内置了BasicErrorController来处理那些没有被具体捕获的异常，这就是为什么即使我们不配置任何异常处理，应用也能返回基本的错误页面。
默认情况下，SpringBoot会根据请求的Accept头来决定返回HTML错误页面还是JSON错误信息。对于浏览器请求通常返回Whitepage错误页面，对于API请求则返回JSON格式的错误信息。
SpringBoot的异常处理机制可以看作是多层过滤器。最先处理的是@ControllerAdvice标注的全局异常处理器，然后是@ExceptionHandler标注的控制器内部异常处理，最后才会落到默认的BasicErrorController。这种分层设计让异常处理既灵活又有序。
在实际项目中，我们通常会覆盖默认的异常处理行为，构建更适合自己业务需求的异常处理体系。这种机制的设计思路值得称赞，它提供了足够的灵活性同时又保持了简洁性。
2.1 使用@ControllerAdvice注解
@ControllerAdvice是Spring框架提供的一个强大注解，它让异常处理变得集中而优雅。这个注解本质上是一个组件注解，Spring在启动时会自动扫描并注册这些被标记的类。
创建一个全局异常处理器只需要在类上添加@ControllerAdvice注解。这个注解告诉Spring：这个类要处理所有控制器抛出的异常。它可以配合@ExceptionHandler注解一起使用，针对不同类型的异常提供专门的处理方法。
我遇到过这样一个场景：项目中有几十个Controller，每个都要处理参数校验异常。使用@ControllerAdvice后，只需要在一个地方编写校验异常的处理逻辑，所有控制器都能受益。代码量减少了至少三分之一，而且后续维护也方便很多。
@ControllerAdvice还支持限定作用范围。通过annotations、basePackages等属性，可以指定只处理特定控制器或特定包下的异常。这种细粒度控制在实际项目中很有用，特别是微服务架构下不同模块可能需要不同的异常处理策略。
2.2 自定义异常处理器
自定义异常处理器让我们能够根据业务需求打造专属的异常处理流程。基本步骤包括创建异常处理类、定义异常处理方法、配置异常响应格式。
先创建一个类并用@ControllerAdvice标记，然后在方法上使用@ExceptionHandler指定要处理的异常类型。方法参数可以接收异常对象、Http请求等，返回值可以是ResponseEntity、自定义响应对象或者视图名称。
处理方法的灵活性很高。你可以获取异常的详细信息，根据请求类型返回不同的响应格式，记录异常日志，甚至根据异常严重程度发送告警通知。这种设计让异常处理不再只是简单的错误信息返回，而是成为了系统监控和运维的重要环节。
实际开发中，我习惯为每个业务模块定义专属的业务异常类。比如订单模块有OrderException，用户模块有UserException。然后在全局异常处理器中为每种业务异常提供定制化的处理逻辑。这种做法让异常处理更加精准，也便于问题定位。
2.3 异常处理优先级与执行流程
理解异常处理的优先级很重要，这能帮助我们在复杂场景下预测异常的处理结果。SpringBoot的异常处理遵循特定的执行顺序。
最优先的是控制器内部的@ExceptionHandler方法。如果当前控制器中定义了针对某类异常的处理方法，那么该异常会首先被这个方法捕获。这种设计允许我们在全局处理的基础上，为特定控制器提供特殊处理。
其次是@ControllerAdvice标注的全局异常处理器。当控制器内部没有匹配的异常处理方法时，Spring会寻找全局处理器。如果有多个全局处理器都能处理同类型异常，还需要考虑@Order注解定义的顺序。
最后才是SpringBoot默认的BasicErrorController。只有当所有自定义异常处理器都没有处理某个异常时，才会进入这个最后的保障环节。了解这个流程有助于我们在适当的地方放置适当的异常处理逻辑。
我曾经调试过一个奇怪的问题：某个异常总是被默认处理器捕获，而不是我自定义的处理器。后来发现是因为异常类型不匹配，自定义处理器处理的是RuntimeException，而实际抛出的是其子类。这种细节问题在理解执行流程后就很容易解决了。
2.4 常见异常类型处理示例
处理参数校验异常是日常开发中最常见的场景之一。当使用@Valid进行参数校验时，如果校验失败会抛出MethodArgumentNotValidException。在异常处理器中，我们可以提取具体的校验错误信息，组装成友好的响应返回给前端。
数据库操作异常也需要特别关注。比如DataIntegrityViolationException通常表示数据完整性约束被违反，可能是唯一索引冲突或者外键约束问题。处理这类异常时，应该将技术性的数据库错误信息转换成业务层面能理解的提示。
空指针异常和数组越界异常属于编程错误，在生产环境中应该被妥善处理并记录详细日志。这类异常的处理重点不是给用户返回具体错误信息，而是记录足够的上下文信息供开发人员排查问题。
网络超时和第三方服务调用异常在分布式系统中很常见。处理这类异常时，除了返回友好的用户提示，还应该考虑重试机制和熔断策略。异常处理器可以在这里集成一些基本的容错逻辑。
文件上传大小超限异常的处理也值得注意。SpringBoot有默认的文件大小限制，超过限制会抛出MaxUploadSizeExceededException。在全局异常处理器中捕获这个异常，可以返回统一的错误信息，避免暴露服务器配置细节。
3.1 统一异常响应格式设计
统一的异常响应格式让前端开发变得轻松。想象一下，每个接口返回的错误信息结构都不一样，前端同事可能要写十几套错误处理逻辑。这种情况在实际项目中并不少见。
我建议设计一个标准的错误响应体，包含错误码、错误消息、时间戳和请求路径这几个核心字段。错误码可以进一步细分为系统级错误码和业务级错误码。系统级错误码比如10001代表参数错误，10002代表权限不足；业务级错误码则根据具体业务模块划分。
时间戳字段很有用。当用户反馈问题时，通过时间戳就能快速定位到具体的错误日志。请求路径字段帮助我们在微服务架构下追踪请求的完整调用链。
记得有次排查线上问题，用户只说了“刚才操作失败了”，但没记住具体时间。幸好我们的错误响应里包含了精确到毫秒的时间戳，很快就找到了对应的错误日志。这种设计在关键时刻能节省大量排查时间。
3.2 业务异常与系统异常分离
业务异常和系统异常应该区别对待。业务异常是预期内的异常，比如用户提交的订单金额超过限额，或者尝试购买已下架的商品。这类异常不需要告警，但要给用户明确的提示。
系统异常则是意料之外的，比如数据库连接超时、Redis集群不可用。这类异常需要立即告警，开发团队要第一时间介入处理。
我习惯为业务异常创建专门的继承体系。基础业务异常类包含错误码和错误消息，各个业务模块再派生出具体的异常类。系统异常则直接使用RuntimeException或其标准子类。
处理时的区别也很明显：业务异常直接返回错误信息给用户，系统异常则记录详细日志但只给用户返回通用提示。这种做法既保证了用户体验，又不会暴露系统内部细节。
3.3 异常日志记录与监控
异常日志不能简单调用e.printStackTrace()。那种做法在分布式系统中几乎毫无用处，你根本不知道这条日志来自哪个服务、哪个实例。
完善的异常日志应该包含请求ID、用户信息、操作类型、异常堆栈等关键信息。如果使用了ELK或类似的日志平台，还可以加上特定的日志级别和标签。
监控方面，我比较推荐使用Metrics体系。通过计数器统计各类异常的发生频率，当某种异常在短时间内大量出现时自动触发告警。这种主动监控比被动查看日志要高效得多。
有个实际案例让我印象深刻：某个服务的数据库连接异常在凌晨突然增多，监控系统立即发出了告警。团队及时处理，避免了早高峰时段的业务中断。如果没有这套监控，等到用户投诉时可能已经造成了严重影响。
3.4 常见问题排查与解决方案
“为什么我的自定义异常处理器不生效？”这是新手最常遇到的问题。首先要检查类是否被Spring管理，是否加了@ControllerAdvice注解。然后确认异常类型是否匹配，有时候父类异常处理器可能拦截了子类异常。
异常信息泄露是另一个需要警惕的问题。生产环境中，详细的异常堆栈可能包含敏感信息。通过全局异常处理器，我们可以对不同类型的异常进行信息脱敏处理。
循环异常处理也要特别注意。如果异常处理器本身抛出异常，就会陷入死循环。好的做法是在异常处理器中加入熔断机制，比如同一个请求的异常处理最多执行三次。
性能问题往往被忽略。过于复杂的异常处理逻辑会影响系统响应时间。我曾经优化过一个项目，把异常处理中的数据库查询改成了缓存获取，接口响应时间直接减少了30%。异常处理不仅要正确，还要高效。