服务降级需联动超时、重试、熔断，兜底逻辑须纯内存计算且可热更新，并配备熔断隔离与可观测性监控。
服务降级不是加个 fallback 就完事
Go 里没有像 Spring Cloud 那样开箱即用的 @HystrixCommand，强行套用“降级=try-catch+默认值”会掩盖真实问题：超时未控制、熔断未触发、兜底逻辑本身也挂了。真正的服务降级必须和超时、重试、熔断联动，且兜底数据要能快速返回（不能查数据库、不能调下游）。
用 context.WithTimeout 控制主链路，失败才走兜底
降级的前提是主调用明确失败，而不是卡住或慢到不可接受。必须给每个外部依赖调用设置合理超时，否则兜底永远不触发。
-
context.WithTimeout是 Go 标准做法，不要用time.AfterFunc或手动 goroutine + channel 模拟 - 超时时间要小于上游整体 SLA，比如 API 要求 P99 ≤ 200ms，下游 HTTP 调用建议设为 100ms
- 兜底逻辑必须是纯内存计算或读本地缓存，禁止再发起任何 I/O
func getUser(ctx context.Context, id int) (*User, error) {
// 主调用带超时
ctx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
defer cancel()
<pre class='brush:php;toolbar:false;'>user, err := httpCall(ctx, id) // 这里用 http.Client.Do 并传入 ctx
if err != nil {
// 超时、连接拒绝、5xx 等都会进这里
return fallbackUser(id), nil // 注意：返回 nil error，业务继续
}
return user, nil}
兜底数据不能硬编码，得支持热更新和分级
上线后发现兜底值写死了（比如所有用户都返回 &User{Name: "default"}），一出问题全量错误。实际中兜底要有层级：ID 可查就查缓存，查不到再用模板生成，模板参数也要可配。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map或go-cache存最近兜底结果，避免重复构造 - 兜底模板存在本地 JSON 文件或配置中心，通过
fsnotify监听变更 - 对关键字段（如价格、库存）做校验，兜底值不能违反业务约束（例如价格不能为负）
var fallbackCache sync.Map // key: userID, value: *User
<p>func fallbackUser(id int) <em>User {
if u, ok := fallbackCache.Load(id); ok {
return u.(</em>User)
}
// 生成兜底：用 ID 哈希决定头像、固定昵称、状态置为 offline
u := &User{
ID: id,
Name: "游客_" + strconv.Itoa(id%1000),
Avatar: fmt.Sprintf("<a href="https://www.php.cn/link/22242fffb164c888879c3513a550427b">https://www.php.cn/link/22242fffb164c888879c3513a550427b</a>", id%10),
Status: "offline",
LastSeen: time.Now().Unix(),
}
fallbackCache.Store(id, u)
return u
}别忘了熔断器，否则兜底会被打爆
如果下游持续超时，每秒 1000 次请求全走兜底，兜底逻辑本身也可能成为瓶颈。必须配合熔断——连续失败 N 次后，直接跳过主调用，强制走兜底，直到休眠期结束。
- 推荐用
sony/gobreaker，它支持自定义cb.State()判断是否开启熔断 - 熔断开启时，
cb.Execute会直接返回cb.ErrOpenState，此时必须返回兜底，且不能记录为新错误（否则永远熔不断） - 注意：熔断器要按依赖粒度隔离，
user-service和order-service不能共用一个实例
var cb *gobreaker.CircuitBreaker
<p>func init() {
cb = gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-fetch",
MaxRequests: 3,
Timeout: 60 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 5
},
})
}</p><p>func getUserWithCircuit(ctx context.Context, id int) (<em>User, error) {
// 熔断器包装主调用
result, err := cb.Execute(func() (interface{}, error) {
return getUser(ctx, id) // 注意：这里才是带超时的真实调用
})
if err != nil {
if errors.Is(err, gobreaker.ErrOpenState) {
return fallbackUser(id), nil // 熔断中，强制兜底
}
return nil, err
}
return result.(</em>User), nil
}最常被忽略的是兜底逻辑的可观测性：有没有记录“本次返回兜底”的日志？有没有监控兜底率突增？有没有在 trace 中标记该 span 是降级路径？没这些，故障时你根本不知道降级是否生效、是否被滥用。
