singleflight仅支持相同key的请求去重，无法自动合并不同key（如user:123与user:456）为批量查询；它不解析key语义、不聚合参数、不改写SQL，仅靠Do方法串行化同key调用，批量逻辑需自行实现聚合层。
singleflight 不是用来做“批处理”的，它只做请求去重；想合并多个不同 ID 的请求为一次批量查询（比如把 user:123、user:456、user:789 合并成 SELECT * FROM users WHERE id IN (123,456,789)），必须自己实现聚合逻辑，singleflight 顶多帮你串行化这个聚合过程。
为什么 Do(key, fn) 不能自动合并不同 key 的请求
singleflight.Group.Do 的设计目标是「相同 key 下的并发请求只执行一次 fn」。它内部用 map[string]*call 管理状态，key 是字符串，完全不感知语义——"user:123" 和 "user:456" 就是两个独立入口，各自排队、各自执行，零合并效果。
常见错误现象：压测时看到 DB 查询数和并发请求数几乎 1:1 上涨，误以为 singleflight 没生效，其实是 key 设计错了，或者根本没理解它的能力边界。
- 它不解析 key 内容，不会把
"user:123"和"user:456"归到同一组 - 它不收集参数、不改写 SQL、不拼 IN 列表，纯靠你传进来的 fn 自己决定干啥
- 如果你的 fn 里每次只查单个 ID，那无论多少并发，它都只会变成 N 个串行单查，不是批量
想真正实现“短时间内的多个 ID 合并为一次批量查询”，得自己搭聚合层
核心思路是：先收请求 → 缓存几毫秒 → 收集同类型 key → 调一次批量接口 → 广播结果给所有等待者。singleflight 可以用来保护这个聚合过程本身不被重复触发，但不能替代聚合逻辑。
立即学习“go语言免费学习笔记（深入）”；
典型结构：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type BatchLoader struct {
mu sync.RWMutex
batch map[int][]chan<- Result // 按业务维度分桶，比如按 user_id mod 100
timer *time.Timer
}
// 外部调用 Load(id) 时，把 id 塞进对应桶，并启动或重置 timer
// timer 触发后，从桶里捞出一批 id，调 db.QueryRowsContext(... IN (...))
// 成功后遍历等待 channel 发送对应结果这时候，你可以用 singleflight.Group.Do("user:batch", fn) 来防止多个 goroutine 同时触发同一批的聚合动作，但注意：
- key 必须稳定，比如
"user:batch:" + strconv.Itoa(bucketID)，不能带时间戳 - fn 内必须包含完整的“取桶→查库→分发”流程，不能只查不发
- 等待 channel 需手动管理生命周期，漏读会导致 goroutine 泄漏
DoChan + 定时器组合是更可控的批处理起点
比起阻塞式 Do，DoChan 返回 ，更适合配合定时器做窗口聚合：
func (l *BatchLoader) Load(ctx context.Context, id int) (User, error) {
key := fmt.Sprintf("user:%d", id)
ch := l.sf.DoChan(key, func() (interface{}, error) {
// 这里不直接查 DB，而是把 id 注册进聚合队列，然后等 timer
return l.triggerBatch(ctx, id)
})
<pre class='brush:php;toolbar:false;'>select {
case r := <-ch:
if r.Err != nil {
return User{}, r.Err
}
return r.Val.(User), nil
case <-ctx.Done():
l.sf.Forget(key) // 主动清理，避免后续请求卡在旧 channel
return User{}, ctx.Err()
}}
关键点：
-
triggerBatch负责把当前 id 加入缓冲区，并检查是否达到阈值或超时，再真正发起批量查询 -
Forget在超时后调用，否则该 key 对应的 channel 会一直挂在那里，内存不释放 - 别依赖
DoChan自动清理——它不关 channel，也不清 map，全靠你主动Forget
最容易被忽略的性能陷阱：聚合窗口太短 or 太长
窗口设成 1ms，可能根本收不到第二个请求，退化成单查；设成 100ms，首字节延迟直接拉高，用户体验变差。真实系统里需要动态调优：
- 观察 P95 批量大小：如果长期 ≤ 2，说明窗口太短或并发不够
- 监控平均等待延迟：超过 5ms 就要考虑拆桶或降窗口
- DB 连接池要够用：一次批量查 100 个 ID，不等于只占 1 个连接，结果集大时可能更耗资源
singleflight 本身不参与这个权衡，它只是你聚合逻辑外的一层安全锁。真正难的是让“收请求”和“发批量”在延迟与吞吐之间找到那个刚刚好的点。
