go无内置分布式缓存，需依赖redis/etcd等外部服务；单机缓存如sync.map无法跨节点，redis常用go-redis/v9实现带过期读写，须用SetNX防覆盖、GetOrLoad防击穿、合理配置连接池；etcd适合强一致元数据管理，通过lease控制TTL并watch变更；go-cache/bigcache仅为单机缓存，多副本下无法同步；分布式缓存核心难点是失效时机与失败回退机制。
Go 本身没有内置分布式缓存，必须依赖外部服务（如 Redis、etcd）或组合库实现；直接用 sync.Map 或 map 只能做单机缓存，跨进程/节点即失效。
用 redis.Client 实现带过期的分布式读写
最常用路径是通过 github.com/go-redis/redis/v9 连接 Redis 集群或哨兵。关键不是“存”，而是控制一致性与失败回退：
-
SET key value EX 300 NX对应client.SetNX(ctx, key, value, 5*time.Minute)，避免并发写覆盖 - 读取时用
client.Get(ctx, key)，但必须检查err == redis.nil（键不存在）而非泛化 Error 处理 - 不要在
Get后手动判断空值再查 DB——应封装成GetOrLoad(key String, loadFunc func() (any, error))，内部用 lua 脚本或双检锁防击穿 - 连接池配置容易被忽略：
Opt.MaxConnAge设为 30 分钟可缓解 Redis 连接老化导致的 timeout
用 etcd 实现强一致的分布式缓存元数据
Redis 快但最终一致；若需缓存生命周期与服务注册强绑定（例如：某配置变更后所有节点必须同步失效对应缓存），etcd 的 watch + lease 更合适：
- 缓存内容仍可存在 Redis，但 key 的 TTL 控制权交给 etcd 的 lease：用
client.Grant(ctx, 60)创建租约，再client.Put(ctx, "cache:config:v1", "", client.WithLease(resp.ID)) - 监听该 key 变更：
client.Watch(ctx, "cache:config:", client.WithPrefix())，收到事件后主动清理本地或远程缓存 - 注意 etcd 的
Put不支持设置过期时间字符串，必须显式绑定 lease ID；忘记传WithLease就等于永久缓存
避免用 go-cache 或 bigcache 做“分布式”假象
这两个库常被误用于分布式场景，实际它们只是高性能单机内存缓存：
立即学习“go语言免费学习笔记（深入）”；
-
bigcache的BigCache实例不共享内存，每个 Go 进程一份，K8s 多副本下各缓存独立，更新无法同步 -
go-cache的expirationCheckInterval是 goroutine 定时扫表，无法触发跨节点回调，也不支持外部失效指令 - 若真要多节点协同，必须外接消息通道（如 Redis Pub/Sub 或 kafka）广播 invalidation 事件，不能靠库自身机制
分布式缓存真正的复杂点不在“怎么存”，而在“什么时候删”和“删不掉怎么办”。比如 Redis 网络分区时，客户端可能收不到失效指令，此时需要结合本地时间戳+版本号做二级校验，而不是相信一次 DEL 调用就万事大吉。