微服务架构下Java全局异常处理的重复建设问题

微服务架构拆分了业务边界，也拆散了曾经属于单体应用的“统一异常处理”。每个服务都各自为政，Java 全局异常处理仿佛陷入了“每个团队都要造一个轮子”的循环：你写一个 `@RestControllerAdvice`，我也写一个，看似都有，实则每个服务的错误码、响应结构、日志级别、告警埋点全不一样。当系统越来越庞大，这种重复建设会逐渐演变成一种隐性的治理负债。

重复的不是代码，而是“约定”

在很多微服务团队里，`GlobalExceptionHandler` 几乎是每个服务的标配。但仔细对比就会发现，服务 A 的响应是 `{ code, message, data }`，服务 B 是 `{ status, error, path }`，服务 C 直接抛了个 `RuntimeException` 给网关，连个统一格式都没有。每个服务都在处理相同的业务异常、参数校验异常、HTTP 状态码映射，但最终呈现给调用方的却是混乱的“方言”。

问题根源在于：我们以为“全局异常处理”是每个服务的内部实现细节，但实际上它属于接口契约的一部分。当服务间互相调用时，异常响应就是另一种形式的 API。你在 A 服务里根据 `code=1001` 做重试，到 B 服务又得先解析它 `code` 字段是否叫 `errorCode`。下游一改，上游就要跟着改，开发者被迫把大量精力花在理解对方的异常语义上，而不是处理真正的业务问题。

重复建设的代价：维护成本乘以服务数量

假设一个标准化异常处理模块需要 500 行代码。如果每个服务都独立实现一遍，那么 N 个服务就是 N 份 500 行代码——正好是重复建设最直观的数学表达。但真正的成本不在代码量，而在于后续的每次变更。

当公司要求统一补全 traceId 透传，或者要求在异常日志里加入环境标签时，你需要去改多少个服务？当安全团队要求对所有校验失败返回 400 而不是 422 时，又有多少服务的测试案例要同步重写？重复建设导致每一次基础设施层的策略调整都变成了一场跨团队的“寻宝游戏”。更致命的是，不同服务的实现者水平参差不齐，有的异常处理器吞了日志，有的把敏感信息直接泄露给前端，这些问题在单体时代被一个类集中解决，在微服务时代却被复制成了分散的不可控风险。

如何打破重复：把异常处理提升为“平台能力”

解决重复建设，不是不允许每个服务自定义异常逻辑，而是要把“全局异常处理”从应用的内部短板中抽离出来，沉淀为公共基础组件。比如在 Java 生态里，可以创建一个 `spring-boot-starter-common`，只专注于定义异常码枚举、统一响应体、日志埋点、安全过滤，再通过 Spring Boot 的自动配置机制让每个服务引用即可。服务只需要继承这个 starter，并注册自己的业务异常类，就能获得一致的响应语义和容错策略。

更进一步，可以在 API 网关层做一个大兜底，把服务逃逸出来的未捕获异常按标准格式包裹后返回给客户端。这样即使某个服务漏配了 starter，也不会破坏整体的一致性。这也是“平台工程”思维的体现：不同团队不必在同一件事上重复发明，而是由平台提供“默认正确”的实现。

警惕过度统一，保留业务的合理差异

不过也要泼一盆冷水：统一不等于做成一潭死水。不同领域服务的错误语义天然有差异——支付服务可能更需要细粒度状态码回滚，而内容服务可能只需要简单提示用户稍后重试。所以全局异常处理的“全局”应当是有边界的：公共协议、响应格式、日志规范必须统一，但业务错误码的编码规则、特定异常是否需要告警、以及重试策略，应当允许各服务通过配置或扩展接口来自定义。

给平台留出扩展点，给团队留出表达空间，才能真正消除重复建设，而不是用一种新的大一统去压制另一种必要的多样性。

回到本文开头的场景：微服务不是把单体里的异常处理切碎，而是要在更基础的地方建立共识。真正该被“去重”的，不是某个类或某段注解，而是对错误语义的定义、对响应契约的表达、对故障处理方式的共同理解。当每个服务都能依赖同一个异常处理底座，开发团队才能把精力放回业务本身——这比少写几百行重复代码重要得多。