微服务错误语义面试题：HTTP状态、业务错误码、可重试与结果未知
本页只放面试标准回答和原理跳转。完整分层模型、错误响应契约、JDK 8 Demo、商业场景和 Runbook 见微服务错误语义。
高频问题
| 问题 | 标准回答 | 原理页 |
|---|---|---|
| 微服务错误为什么要分类 | 因为参数错、权限拒绝、库存不足、限流、熔断、连接失败、读取超时、下游500和解码失败的处理方式完全不同。分类后才能决定是否重试、是否降级、是否查询事实、是否报警。 | 错误分层 |
| HTTP状态码和业务错误码怎么分工 | HTTP状态表达协议大类，例如400参数非法、401未认证、403无权限、429限流、503不可用；业务code表达领域结果，例如库存不足、支付状态未知。程序判断应依赖稳定code，不依赖message。 | HTTP与业务码 |
| 为什么超时不是失败 | 超时只说明调用方在等待窗口内没收到响应，下游可能没执行，也可能已经提交但响应丢失。写请求超时应进入UNKNOWN，用幂等键查询事实，而不是换请求号重试。 | SUCCESS/FAILED/UNKNOWN |
| 哪些错误可以重试 | 必须同时满足瞬时错误、操作幂等或无副作用、剩余Deadline足够、重试预算未耗尽。连接建立失败、503、部分死锁可有限重试；参数错误、权限拒绝、库存不足、解码失败通常不应重试。 | 重试分类 |
| 429返回后客户端怎么办 | 429表示被限流，请求通常不应立即重试。客户端应按Retry-After或退避抖动等待，并受总Deadline和重试预算限制；否则会制造限流重试风暴。 | 重试分类 |
| Feign的ErrorDecoder能处理所有业务错误吗 | 不能。ErrorDecoder通常处理非2xx HTTP响应。如果系统用HTTP 200承载业务失败码，ErrorDecoder不会自然触发，必须在Decoder或统一响应检查中处理业务code。 | 框架映射 |
| gRPC UNKNOWN是不是都可以重试 | 不能。UNKNOWN可能是未正确映射的错误，也可能掩盖业务异常。应按状态码、错误详情、幂等性和提交边界判断；不能把库存不足伪装成UNAVAILABLE诱导重试。 | 框架映射 |
| 降级返回为什么不能伪装成功 | 降级是保核心能力，不是改业务事实。推荐失败可以返回空列表，库存失败不能返回库存充足，支付超时不能默认成功或失败。强语义接口应返回FAILED或UNKNOWN并查询事实。 | 错误响应契约、商业场景 |
| 业务错误是否应该计入熔断失败率 | 要分类。下游500、连接失败、读取超时通常可计系统失败；库存不足、参数错误、权限拒绝是明确业务结果，不应直接算下游故障。否则正常业务拒绝也会把熔断器打OPEN。 | Runbook |
| 接口HTTP 200是不是就代表成功 | 不一定。HTTP 200只能说明服务按协议返回了响应，业务还要看success、code、state和degraded。长期降级也可能都是200，但用户实际拿到的是不完整结果。 | HTTP与业务码 |
| 错误响应里为什么要有traceId | traceId把客户端错误、Gateway、调用方、下游、日志和Trace串起来。对用户隐藏内部堆栈，但给排查人员留下可定位证据。traceId不是幂等键。 | 响应契约 |
场景题：库存服务Read Timeout后能不能重试
不能直接换请求号重试。Read Timeout 表示调用方没收到结果，但库存服务可能已经冻结成功。应使用同一个业务幂等号查询库存冻结流水；成功则推进订单，失败则明确失败，未知则待确认或对账。只有确认请求未到达或操作幂等且预算允许，才考虑有限重试。
场景题：熔断器为什么被业务错误打爆
可能把库存不足、参数错误、权限拒绝这类明确业务失败统一抛成系统异常并计入失败率。应重新梳理错误码和异常映射，把业务拒绝与系统故障分开；系统故障计入熔断，业务拒绝返回稳定code但不触发下游故障判断。
项目回答模板
我们会把错误分为传输、协议、框架、业务和数据几类。HTTP状态表达协议大类，业务code表达领域结果，响应里包含traceId、retryable、state和受控details。写请求超时统一进入UNKNOWN，用幂等号查询事实；参数、权限、库存不足不重试；连接失败、503和死锁这类瞬时错误才在Deadline和预算内有限重试。降级必须保留degraded标记，不能把库存、支付这类强事实伪装成功。
本章小结
错误语义面试的关键是“看到错误后该做什么”。能讲清可重试、不可重试、结果未知、降级语义和事实查询，才算真正理解微服务调用可靠性。