singleflight.Do 能防止缓存击穿，因为它对同一 key 的并发调用仅允许首个 goroutine 执行函数，其余阻塞等待并共享结果，将“1000 次 DB 查询”降为“1 次查询+999 次等待”。
singleflight.Do 为什么能拦住缓存击穿
因为 Do 对同一个 key 的所有并发调用，只让第一个 goroutine 真正执行函数，其余全部阻塞等待——结果返回后，所有人拿到同一份值。这直接把“1000 个请求同时查 DB”压成“1 个查，999 个等结果”。
- 它不关心缓存是否存在，也不管你有没有写入缓存，只管“此刻这个 key 的加载动作是否已在进行中”
- 适合场景：DB 查询快（
- 不适合场景：加载逻辑本身慢或不稳定（比如跨机房 RPC 超时率高），失败时所有等待者一起失败，可能放大雪崩
不配缓存，singleflight 就是废柴
singleflight.Group 本身不存任何数据，Do 返回的值也不会自动进缓存。如果每次调用都走 Do，等于反复触发去重+等待，但没省下一次 DB 查询——因为下次来还是 miss。
- 必须自己在
Do的回调里完成“查 DB → 写缓存”闭环，例如用sync.Map或 Redis 客户端写入 - 常见错误：写了
g.Do("user:123", loadFromDB)，但 loadFromDB 里没调cache.Store()，导致下次请求又进Do - key 设计要一致：缓存 key、singleflight key、DB 查询条件三者必须对齐，否则去重失效（比如一个用
"user:123"，一个用"u123"）
shared 字段不是装饰，是关键信号
Do 返回的 shared 布尔值告诉你：“这个结果是不是被别人算出来的”。它不表示缓存命中，而是表示“你没执行函数，只是拿了别人的结果”。
- 可用于日志打点：
if !shared { log.Info("first load for key", "key", key) } - 不能用来判断缓存是否有效——哪怕
shared=true，结果也可能已过期，得靠缓存层自己控制 TTL - 别忽略 error：如果第一次执行出错，
shared=true时所有等待者也拿到同一个error，需结合重试策略或降级逻辑
Group 生命周期和错误处理容易翻车
singleflight.Group 是无状态的，但它的生命周期管理常被忽视：全局变量长期持有没问题，但如果按请求或租户新建 Group，会导致内存泄漏且去重失效。
立即学习“go语言免费学习笔记（深入）”；
- 推荐做法：整个服务共用一个全局
var g singleflight.Group，不要按 context 或参数 new - 错误处理不能只依赖
Do的 error 返回：DB 查询失败时，应考虑写空值缓存（防穿透）或 fallback 默认值，而不是让所有请求卡死在失败结果上 - 超时要由外层控制：
singleflight本身不支持超时，得用context.WithTimeout包裹实际加载函数，并在函数内检查ctx.Err()
