singleflight.Group.Do本身不会panic，panic源于后续对返回值v的不安全类型断言（如v.(User)）；必须用v, ok := v.(User)兜底或统一包装返回值，且key需精确唯一、fn须无副作用。
直接结论：用 singleflight.Group.Do 就行，但 key 设计、fn 无副作用、类型断言处理这三点不注意，反而会引入 panic 或逻辑错乱。
为什么 Do 会 panic？类型断言没兜底
常见错误是把 Do 返回的 v interface{} 直接强转，比如 v.(User)。一旦 fn 返回了 nil 或非预期类型（比如 error 被忽略后继续断言），运行时就 panic。
- 必须先判断
v != nil，再检查具体类型；更稳妥的做法是用类型开关或反射前加ok判断 - 如果
fn可能返回多种类型（如*User或error），建议统一包装成结构体返回，避免多层断言嵌套 - 不要依赖
shared布尔值做业务分支——它只表示“是否共享结果”，和数据有效性无关
key 怎么设才不会漏合并或误合并？
key 是合并逻辑的唯一依据，错一点就全失效。比如查用户，"user:123" 和 "user:id=123" 在 Do 看来是两个完全不同的请求。
- 拼接 key 时，所有影响结果的参数都得参与，比如
fmt.Sprintf("user:%s:%s", id, region)，不能只用id - 避免带不确定字段：时间戳、随机数、traceID 这类绝对不能进 key
- 如果上游传的是 JSON 字符串，别直接当 key——先解析再排序字段再序列化，否则相同语义不同顺序的 JSON 会被当成不同 key
DoChan 用不好反而卡死 goroutine
DoChan 返回一个 chan singleflight.Result，看起来能异步，但实际容易踩内存泄漏和阻塞坑。
- channel 不会自动关闭，如果没人从 channel 读，它会一直挂在那里，对应的
call对象也无法被 GC - HTTP handler 里用
DoChan后直接 return，又没起 goroutine 去接收，等于埋了个定时内存炸弹 - 超时控制得自己做：
select { case r := ，不能只等 channel
Forget 不是“清缓存”，是主动放弃等待
Forget 的作用常被误解为“让下次请求重新走逻辑”，其实它只是把当前 pending 的 call 从 map 里删掉，后续同 key 请求会新建 call 并执行 fn。
- 典型适用场景：你知道某个 key 永远不会再成功了，比如用户已被软删除，再查 DB 也只会返回 not found，那就
g.Forget("user:123")，省得新请求还排队等那个注定失败的结果 - 它不清理任何已缓存的数据，也不影响你自己的 cache 层；别指望靠它刷新 Redis 或 sync.Map
- 频繁调用
Forget可能导致大量短命call对象，GC 压力上升，慎用
真正难的不是调用 Do，而是让 key 稳定、fn 干净、结果安全落地——这三个点漏掉任意一个，singleflight 就从减压阀变成故障放大器。
