Go微服务无自动降级机制，必须手动判断errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled)，fallback函数需签名严格匹配、无副作用、仅用本地数据，且须与熔断器和动态开关协同。
Go 微服务没有自动降级机制，所有降级逻辑必须手动触发、显式编写、严格校验——这不是配置开关就能生效的事，而是每次调用后都要做判断、每个 fallback 都要过编译、每条路径都要防雪崩。
如何判断该不该走降级分支
降级只对瞬时故障有效，不是所有 err != nil 都该进 fallback。关键在错误语义区分：
-
errors.Is(err, context.DeadlineExceeded)和errors.Is(err, context.Canceled)必须同时检查；漏掉context.Canceled会导致上游主动中断时直接返回 500 - gRPC 场景下，
status.FromError(err).Code()可能是codes.DeadlineExceeded，但底层仍是 context 错误包装，仍要走errors.Is判断 - HTTP 错误中
"dial tcp: i/o timeout"可降级，404 Not Found是业务正常态，不应触发 fallback - 数据库操作中
sql.ErrNoRows不是错误，是预期结果；而"connection refused"才该走降级
fallback 函数签名和返回值怎么写才不报错
Go 编译器会严格校验降级函数与主逻辑的类型一致性。常见编译失败原因：
- 主函数是
func GetUser(ctx context.Context, id string) (*User, error)，降级函数就必须是func(context.Context, string) (*User, error) - 少一个参数、多一个参数、
*User写成User、error写成string，全都会编译失败 - 别写
func() *User或func() error：熔断库（如go-zero的DoWithFallbackCtx）只接受签名完全匹配的函数 - 返回
nil, err合法，但前端可能收不到数据；更推荐返回&User{Name: "guest", Age: 18}，避免零值歧义
为什么降级里不能发起新网络请求
这是雪崩最常被忽略的入口。一旦 fallback 中调了 Redis、HTTP 或 gRPC，等于把故障从 A 服务传导到 B，再传导到 C。
立即学习“go语言免费学习笔记（深入）”；
- 禁止在降级路径中调用
http.Get、redis.Client.Get、任何带context.Context的异步操作 - 静态值优先：用本地变量或常量初始化结构体，例如
var defaultUser = &User{Name: "system", Status: "offline"} - 缓存可读，但必须是本地内存缓存（如
sync.Map或bigcache），且加载发生在服务启动时，而非降级路径中 - 别起 goroutine 去“异步兜底”——降级必须是同步、无副作用、秒返回的
熔断器和人工开关怎么协同才可靠
纯靠熔断器覆盖不了「依赖方主动维护中」这类非错误场景；纯靠人工开关又缺乏实时性。两者必须联动，且有明确优先级：
- 定义组合判断函数
NeedFallback(service string) bool，内部同时查breaker.State()和配置中心config.GetBool("downgrade." + service) - 优先级设为「人工开关 > 熔断状态」：人工开启时，绕过熔断器直接走降级；熔断打开时，自动触发；两者都关闭才允许真实调用
- 每个降级分支必须打日志 + 打点，例如
metrics.Counter("user_service_fallback_total").Inc()，否则无法感知是否被误触发 - 降级开关必须从 etcd/Nacos 加载，并定期刷新，硬编码等于没开关
真正难的不是写 fallback 函数，而是让每个开发都记住：降级不是兜底容错，而是主动切换路径；它比主流程更严苛——不能发请求、不能改状态、不能起 goroutine、不能依赖任何外部资源。稍一松懈，兜底就变成导火索。
