groupcache不是开箱即用的去中心化缓存，需手动配置HTTPPool节点通信、显式设Transport超时、严格遵守GetterFunc纯函数契约，且cacheBytes为硬内存上限。
groupcache 不是开箱即用的去中心化缓存，它不自动发现节点、不处理网络分区、也不做健康检查——直接跑通 NewGroup 示例代码，线上服务大概率会卡死或缓存错乱。
HTTPPool 配置错一个地址，整个 peer 请求就 404
groupcache 节点间通信完全依赖 HTTPPool，不是 DNS 或服务注册中心。常见错误包括：
-
BaseURL写成"http://127.0.0.1:8000"，但实际http.ListenAndServe(":9000", nil)监听在 9000 端口，导致本地 miss 后发请求到自己却返回 404 -
pool.Set([]string{...})传入了已下线节点（如"http://10.0.1.105:8000"），而groupcache默认不探测存活，会持续重试并拖慢所有Get - 没配
Transport超时，peer 请求卡住几十秒，连带阻塞整个 goroutine —— 必须显式设置：DialContext.Timeout、ResponseHeaderTimeout、TLSHandshakeTimeout
GetterFunc 不是普通回调，它有纯函数契约
NewGroup 第三个参数是 groupcache.GetterFunc，它不是“加载完塞进缓存”那么简单：
- 必须把数据写入
dest（比如调用dest.SetBytes(...)），否则Get返回成功但缓存里没东西 - 不能启动新 goroutine：singleflight 合并请求时，若你在里面起 goroutine 并发写
dest，会竞态崩溃 -
ctx必须透传到底层：比如传给db.QueryRowContext(ctx, ...)或http.DefaultClient.Do(req.WithContext(ctx))，否则超时和 cancel 无效 - 不能修改外部状态（如全局 map、文件、日志句柄），否则 singleflight 下多个 key 共享同一实例时行为不可控
cacheBytes 是硬上限，不是建议值
设成 64 就真只用 64MB，超出部分由 LRU 淘汰，但不会报警、也不会扩容：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 设太小（比如
1 ）会导致高频 key 反复进出，命中率暴跌；尤其在高并发读同 key 场景下，LRU 频繁驱逐又重载，CPU 和后端压力双升 - 设太大（比如
2 ）可能挤占其他组件内存，Go GC 压力增大；且 groupcache 不分代管理，所有 key 统一走 LRU，冷热混杂时效果打折 - 没有 TTL、没有主动失效机制，过期逻辑得靠业务层兜底（比如 key 带时间戳前缀，或定期重建 Group）
Get 返回成功 ≠ 数据进了缓存
Get 是否落本地缓存，取决于你传的 Sink 实现：
立即学习“go语言免费学习笔记（深入）”；
-
groupcache.AllocatingByteSliceSink(&data)是最常用写法，它会把数据拷贝进&data指向的 slice，并触发本地缓存写入 - 如果你自己实现
Sink，忘了调用SetXXX方法（如SetString、SetBytes），Get仍可能返回nilerror，但数据根本没进缓存 - 本地缓存写入发生在
GetterFunc执行完毕后，如果GetterFuncpanic 或提前 return error，缓存不会写入
pool.Set() 列表。某个节点挂了？得靠外部哨兵重启 + 配置同步，否则请求持续失败。这些细节不写死在启动逻辑里，跑一周后缓存一致性就不可信了。 
