redis连接失败时get不会自动panic，需手动判断错误类型并实现兜底重试与fallback；应区分redis.nil（键不存在）与网络类错误，避免误降级污染缓存。
Redis 连接失败时 Get 直接 panic？先加兜底重试和 fallback 标志
Go 的 Redis 客户端（比如 github.com/go-redis/redis/v9）默认遇到网络断连或超时，Get 会返回 redis.Nil 或具体错误（如 redis: nil、context deadline exceeded），但不会自动降级。你得自己判断错误类型，再决定是否查本地缓存。
常见错误现象：服务上线后 Redis 突然抖动，大量请求报 redis: nil 或连接拒绝，接口 500 暴增——其实数据在本地内存里就有，只是没走 fallback 路径。
- 用
errors.Is(err, redis.Nil)区分「键不存在」和「连接失败」；真正的连接问题通常伴随net.OpError或上下文取消 - 别只靠
err != nil就跳转本地缓存——这会把「键确实不存在」也误判为故障，导致本地缓存写入空值，污染后续读取 - 建议对 Redis 错误做分类封装，例如定义
IsRedisUnavailable(err error) bool，内部检查是否含"timeout"、"connection refused"、"i/o timeout"等关键词（注意：生产环境慎用字符串匹配，优先用客户端自带的错误判断）
本地缓存选 sync.Map 还是 bigcache？看读写比和 GC 压力
sync.Map 是标准库方案，零依赖、够轻量，适合中小规模（万级 key 以内）、读多写少的降级场景；bigcache 或 freecache 更适合高吞吐、需要 TTL 和内存控制的场景，但引入了额外依赖和序列化开销。
性能影响明显：如果每次降级都 new struct 再 json.Marshal 存进 sync.Map，GC 压力会陡增；而 bigcache 要求 value 是 []byte，得手动处理编解码。
- 简单降级：直接存
interface{}到sync.Map，避免序列化；用time.Now().Add(ttl)手动管理过期（查的时候比对时间戳） - 需要自动过期：选
bigcache.NewBigCache(...)，但注意它不支持 key 级 TTL，只能设全局lifeWindow，且初始化时shards数量要匹配 CPU 核心数，否则锁争用严重 - 别把本地缓存当主力——它的容量有限，写太多易 OOM；建议加个计数器，当本地缓存命中率持续 >80% 且 Redis 恢复后，主动清空本地缓存，防止 stale data
降级开关要不要配中心化配置？先从进程内 flag 开始
一开始没必要上 etcd 或 Nacos 控制降级开关。Go 服务启动时读一个环境变量（如 DISABLE_REDIS=true）或命令行 flag（-disable-redis），就能快速验证 fallback 流程是否通。
容易踩的坑是：开关逻辑写死在业务函数里，导致测试难 mock；或者开关更新后不 reload，变成“假热更”。
- 把降级决策抽成独立函数，例如
shouldUseLocalCache() bool，内部先查 flag，再查 Redis 连通性探针（比如每 30 秒跑一次PING并缓存结果） - 避免在每次
Get时都调redis.Ping()——这本身就会放大 Redis 不可用时的延迟，改用带缓存的状态机 - 如果真上了配置中心，记得加本地缓存 + 变更监听，别让每次读配置都走网络；变更后要触发本地缓存清理，否则新配置生效了，旧数据还在本地里挂着
本地缓存写入时机：不是所有 Redis Set 都该同步到本地
Redis 不可用时，有些写操作可以丢（比如用户行为埋点），有些必须落本地（比如库存扣减结果）。盲目把所有 Set 都同步到 sync.Map，会导致本地状态和 Redis 恢复后不一致，甚至引发超卖。
关键点在于区分「可丢失写」和「强一致性写」。前者降级期间可跳过；后者必须记录日志或进队列，等 Redis 恢复后重放。
- 读场景降级安全：只要本地有，就返回；没查到再走 DB，不写本地
- 写场景要分类：
cache.Set("order:123", order, ttl)这类业务关键数据，降级时应写本地 + 记 log（如fmt.Fprintln(f, "pending_set order:123")），恢复后扫日志补发 - 别在本地缓存里实现 CAS 或 INCR——
sync.Map没原子增减，bigcache更不支持；这类操作降级时直接返回错误或走 DB，别硬扛
最麻烦的永远不是“怎么切”，而是“切完怎么对齐”。Redis 恢复后，本地缓存里的脏数据、漏写的 key、过期时间偏差……这些细节不处理，降级就成了双写不一致的温床。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
