Go 服务降级：不是所有下游失败都要拖垮主流程

并发聚合接口里，不同下游的重要性不同。用户资料失败可能必须返回错误，推荐位失败却可以返回空列表。降级的核心，是提前区分核心依赖和非核心依赖。

先定义核心路径

核心路径失败会影响业务正确性，应该快速失败；非核心路径失败只影响体验，可以返回默认值、缓存值或空值。

降级也要可观测

如果降级悄悄发生，长期看会掩盖下游问题。每次 fallback 都应该计数，并在日志中带上下游名称和原因。

不要把降级当成吞错误

降级不是忽略错误，而是用业务允许的方式返回。同时要保留排查线索，避免用户看到正常页面，系统却已经持续坏了几小时。

生产场景

适用于推荐、广告、统计、搜索增强、画像标签等非核心依赖。降级让主流程保持可用，但前提是业务能接受替代结果。

关键指标

• fallback 次数按依赖和原因拆分
• 降级期间页面关键业务转化或错误率
• 降级持续时间和恢复时间

常见误区

• 把降级写成吞错误，没有日志和指标
• 核心依赖也随意返回默认值，造成数据错误
• fallback 数据过旧，用户看到误导信息

落地建议

建议在产品和业务层明确哪些依赖可降级、用什么默认值、持续多久需要报警。降级不是隐藏故障，必须能在仪表盘和日志中被快速看到。

代码示例

recommend, err := recClient.List(ctx, uid)
if err != nil {
    metrics.DegradeTotal.WithLabelValues("recommend").Inc()
    recommend = []Item{}
}
return Page{Profile: profile, Recommend: recommend}, nil

上线检查

• 核心/非核心依赖有明确清单。
• fallback 结果符合业务语义。
• 降级次数有报警阈值。