Go微服务降级必须手动实现且严格约束：service层封装决策、纯内存fallback、context超时健壮判断、动态开关与监控。
Go 微服务里没有“自动降级”这回事，降级必须手动判断错误语义、显式跳转、且严格约束降级行为边界——加个 fallback 函数不等于完成降级，它可能根本不会被调用，或者调用时已破坏一致性。
service 层必须封装降级决策，不能塞在 handler 里
handler 层只负责接收请求、校验参数、调用 service 并返回响应。把降级逻辑写在 http.HandlerFunc 里会导致业务耦合、复用困难，也难以统一控制超时和熔断。
- service 方法必须接收
ctx context.Context，并在每次关键调用后立刻判断err，而不是堆到函数末尾统一处理 - 典型错误：在 handler 里写两套 HTTP 调用（主依赖 + 备用依赖），一旦备用逻辑也要加缓存、重试、限流，立刻失控
- 降级分支必须是纯内存计算或读本地 LRU 缓存（如
github.com/hashicorp/golang-lru），禁止再发网络请求、查 DB、起 goroutine - fallback 函数签名必须严格匹配主逻辑，例如
func GetUser(id string) (*User, error)的降级也得返回(*User, error)
只用 errors.Is(err, context.DeadlineExceeded) 或 errors.Is(err, context.Canceled) 判断超时
这是唯一健壮的上下文终止判断方式。很多开发者只写 err == context.DeadlineExceeded，漏掉 context.Canceled，结果上游主动中断（比如前端关闭页面、gRPC 流取消）时直接返回 500，完全没走降级分支。
-
status.FromError(err).Code()可能是codes.DeadlineExceeded，但底层仍是 context 错误包装，仍要走errors.Is判断 - 禁用
strings.Contains(err.Error(), "timeout")：HTTP/HTTP2/gRPC/数据库驱动返回的错误文本不一致，“i/o timeout”、“context deadline exceeded”、“transport: context deadline exceeded”都可能出现 - HTTP 客户端错误中，“dial tcp: i/o timeout”可降级，但 “404 Not Found” 或
sql.ErrNoRows是业务正常态，不应进降级分支
gobreaker.CircuitBreaker.Execute 的 fallback 必须是纯函数
熔断器只管“是否允许执行”，降级逻辑需你显式编写并处理 gobreaker.ErrOpen。填错 gobreaker.Settings.Timeout（单位是毫秒，不是秒）会导致请求在熔断器里直接超时退出，根本没机会执行降级函数。
立即学习“go语言免费学习笔记（深入）”；
- fallback 函数内部不能发新请求、不调
time.Now()、不写日志、不依赖全局变量——并发修改风险高；每次新建开销极小，别省这点内存 - 避免返回零值结构体：
&User{}序列化后是{"name":"","age":0}，前端易误判为真实空数据；改用DefaultUser()显式构造，字段赋值明确 - 别用
hystrix-go：已归档、不支持 Go module clean import；gobreaker更轻、更可控 - 每个依赖服务应隔离 breaker 实例，避免一个服务熔断拖垮全部
降级开关必须可动态配置，不能写死
运维正在灰度升级 user-svc 实例，所有节点临时下线，这时应该由配置中心强制开启降级开关，而不是等熔断器统计失败次数——服务发现不可用 ≠ 必须降级。
- 实现统一判断函数：
func NeedFallback(serviceName string) bool，内部按优先级检查：config.GetBool("downgrade." + serviceName)→breaker.State() == gobreaker.StateOpen→ false - 开关逻辑切忌写死在 handler 里；它必须可被单元测试覆盖，且能响应配置中心的 watch 事件实时更新
- 提供 HTTP 管理接口（如
/admin/degrade/enable?service=user&mode=cache）支持手动开启/关闭某类降级 - 每个降级分支必须打日志 + 打点（如
metrics.Counter("user_service_fallback_total").Inc()），便于快速发现是否被频繁触发
最容易被忽略的是：降级不是“兜底容错”，而是“主动切换路径”。它的行为比主流程更严格，否则会放大故障——比如在 fallback 里调用 time.Now()，看似无害，但在高并发下会成为性能瓶颈；又比如用全局变量存默认实例，在并发场景下可能被意外覆盖。这些细节不处理，降级就只是个心理安慰。
