fallback函数必须是纯函数、签名与主函数一致、返回静态内存常量、无副作用、不依赖上下文或外部状态，否则会panic。
数据库宕机时，fallback 函数怎么写才不 panic？
Go 微服务里直接用 recover() 捕获 DB panic 是错的——panic 会中断 goroutine，且无法区分是连接超时、SQL 错误还是真正宕机。真正的兜底必须在调用前就决定是否走降级，而不是等 db.QueryRow() 崩了再补救。
正确做法是把降级逻辑封装成高阶函数，让业务层只关心“查什么”，不操心“查不到怎么办”：
-
fallback必须是纯函数：不依赖外部状态、无副作用、可并发安全 - 降级函数签名应与原 DB 函数一致，比如
func() (User, error)→func() (User, error)，否则类型擦除后难做统一包装 - 避免在
fallback里读本地文件或访问另一套缓存——这会引入新故障点；静态兜底就该是内存常量或编译期确定的数据
go-zero 的 Breaker.DoWithFallback 为什么总 fallback 失败？
常见错误是把 fallback 写成闭包捕获了 request-scoped 变量（比如 ctx 或 userID），而熔断器执行 fallback 时可能已脱离原始 goroutine，导致 panic 或返回空值。
实操建议：
- 所有 fallback 输入必须提前固化：比如把
userID提前转成字符串传入，而不是在 fallback 里再取ctx.Value - 不要在 fallback 里调用
log或metrics.Inc——这些可能依赖未初始化的全局实例，引发 nil panic - 检查
Breaker配置：errorThreshold默认是 50%，如果 DB 偶发超时但没真宕机，它会过早触发 fallback；建议生产环境设为80%并搭配timeout>db.Timeout
示例：
fallback := func() (User, error) {
return User{ID: 0, Name: "guest", Role: "anonymous"}, nil
}
user, err := breaker.DoWithFallback(func() (User, error) {
return db.GetUserByID(ctx, id)
}, fallback)
静态兜底数据放哪？硬编码、配置文件还是 init 函数？
硬编码最安全：编译期确定、无 I/O、无解析开销。但要注意两点：
- 结构体字段必须和 DB 返回完全一致（包括导出性、tag、零值含义），否则 JSON 序列化或 gRPC 编码会出错
- 如果兜底数据含时间字段（如
CreatedAt time.Time），别用time.Now()—— 这会让每次 fallback 返回不同值，破坏幂等性；应固定为time.Unix(0, 0)或业务允许的默认时间 - 配置文件（如 YAML）加载失败会导致服务启动失败，违背“兜底要可用”的前提；init 函数加载文件也一样——文件缺失即 panic
结论：兜底数据定义在 var 全局变量里，用 struct literal 初始化，不带任何运行时计算。
HTTP handler 里怎么透传降级信号给前端？
不能只靠 HTTP 状态码（比如一律 200 + body），前端需要明确知道“这是兜底数据”。否则用户看到“余额 100 元”却实际查不到真实余额，会误判业务异常。
- 在响应 body 中加字段：
{"data": {...}, "fallback": true}，且该字段必须由降级路径统一注入，禁止业务 handler 自己拼接 - HTTP Header 更可靠：
X-Fallback: db-down，header 名需全小写（Go http 标准库自动 lower-case），值建议用语义化标签而非布尔 - 别用 status code 区分：200 是兜底，503 是服务不可用——但 DB 宕机时你仍能返回兜底，所以不该返回 503
容易被忽略的是日志：每条兜底响应必须打一条 level=warn msg="db fallback triggered" db="user_center"，否则线上出问题时根本没法追溯是哪个依赖触发了降级。
