go微服务降级需手动实现：service层用context判断超时（errors.is）、gobreaker显式调用fallback、本地lru缓存纯内存数据，禁止降级中发起新请求。
Go微服务里没有“开箱即用”的优雅降级模块，所有降级逻辑必须显式编写、手动触发、严格约束边界——框架不兜底，panic不等于降级，fallback函数也不会自动执行。
service层才是降级逻辑的唯一合法落点
handler层只做参数校验和响应包装，把降级塞进去会导致复用困难、熔断失效、超时判断错位。service方法必须接收ctx context.Context，并在每次下游调用后立刻判断错误语义：
- 主调用返回
err != nil时，不能堆到函数末尾统一处理，得立刻分支 - 降级分支只能读本地
LRU cache或返回DefaultUser()这类纯内存构造体 - 禁止在降级里调用
http.Get、db.Query、time.Now()或任何可能阻塞/失败的操作 - 每个
GetUser(id string) (*User, error)的降级函数也必须返回(*User, error)，哪怕error是nil
errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) 是唯一可靠超时判断
很多降级没触发，不是逻辑写错了，而是超时判断方式不健壮：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 别用
err == context.DeadlineExceeded——漏掉context.Canceled会导致前端关闭页面时直接返回500 - 别用
strings.Contains(err.Error(), "timeout")——"i/o timeout"、"context deadline exceeded"、"transport: context deadline exceeded"全都不一样 - gRPC调用失败时，
status.FromError(err).Code()可能是codes.DeadlineExceeded，但底层仍是context错误，仍要走errors.Is - HTTP客户端错误中，
"404 Not Found"或sql.ErrNoRows是业务正常态，不该进降级分支
gobreaker熔断器必须配合显式fallback调用
gobreaker.CircuitBreaker.Execute不会自动跳转到降级函数，它只在熔断打开时返回gobreaker.ErrOpen，你得自己捕获并调用fallback：
-
gobreaker.Settings.Timeout单位是毫秒，填500是500ms，不是5秒——填错会导致请求在熔断器里直接超时退出，根本没机会执行降级 - fallback函数签名必须严格匹配主逻辑，比如都返回
(*User, error)，且内部不能发新请求、不改全局状态、不调rand.Intn() - 别把开关逻辑写死在handler里；用
config.GetBool("downgrade.user_svc")+breaker.State() == gobreaker.StateOpen组合判断是否需要降级 - 人工开关优先级高于熔断状态，运维灰度下线服务时，靠配置中心强制开启降级比等失败率统计更及时
本地LRU缓存是降级稳定性的关键一环
当Redis缓存击穿+下游挂掉，所有请求瞬间涌向降级逻辑，如果每次都要&User{Name: "guest", Age: 18}构造，没问题；但如果降级结果来自远程配置中心或文件读取，就会成为新瓶颈：
- 用
github.com/hashicorp/golang-lru预热默认值，避免重复构造 - 降级数据写入本地LRU时，key要带服务名前缀，比如
"fallback:user:default"，防止跨服务污染 - LRU容量不宜过大，100–500条足够，避免内存浪费；淘汰策略用LRU而非LFU，热点降级项自然保留
- 不要依赖全局变量存默认实例——并发修改风险高，每次新建开销极小，别省这点内存
最易被忽略的点：降级不是“有fallback函数就行”，而是整个调用链路的协同——从context.WithTimeout传入、到errors.Is判断、再到gobreaker.Execute分流、最后落到纯内存fallback，每一步都得手动对齐，缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
