singleflight.Group 是解决请求合并问题的专用工具，它通过 key 去重、串行执行 fn、广播结果并自动清理，避免竞态和泄漏；而 sync.WaitGroup 和 chan 无法识别相同参数的并发请求，map + RWMutex 则易引发 panic 或 goroutine 泄漏。
为什么直接用 sync.WaitGroup 或 chan 无法解决请求合并问题
并发请求合并（request coalescing）不是简单的“等所有 goroutine 完成”，而是要识别出“相同参数、在极短时间内到达”的多个请求，只让其中一个真正发起下游调用，其余等待其结果。用 sync.WaitGroup 只能同步执行，无法去重；用无缓冲 chan 会阻塞新请求，丢失时效性；而单纯用 map + sync.RWMutex 手动管理待合并请求，又极易出现竞态或泄漏（比如 key 永远不被清理）。
- 典型错误现象：
panic: concurrent map read and map write，或某些请求永远收不到响应（goroutine 泄漏） - 关键矛盾点：既要低延迟（不能等太长时间），又要高合并率（窗口期太短则合并失败，太长则拖慢首字节时间）
- 真实场景中，
GET /user?id=123在 10ms 内被触发 7 次，理想情况是只查 DB 一次，6 次复用结果
用 singleflight.Group 实现安全、开箱即用的合并
singleflight.Group 是 Go 标准库 golang.org/x/sync/singleflight 提供的专用工具，它内部用 map + sync.Mutex + chan 封装了完整的“入队-去重-广播-清理”逻辑，无需手动管理生命周期。
- 核心方法是
Do(key string, fn func() (interface{}, error))：相同key的多次调用，仅执行一次fn，其余等待并共享返回值 -
key必须能准确区分请求语义，例如"user:" + strconv.Itoa(id)，而非固定字符串"user" - 注意
fn返回值必须是interface{}，需显式类型断言；错误会被统一透传给所有等待者 - 不自动限流或超时，若
fn卡住，所有同 key 请求都会卡住——务必在fn内部加 context 超时控制
import "golang.org/x/sync/singleflight"
<p>var sg singleflight.Group</p><p>func fetchUser(ctx context.Context, id int) (<em>User, error) {
v, err, _ := sg.Do(strconv.Itoa(id), func() (interface{}, error) {
// 这里只会在首次请求时执行，且自动串行化
u, err := db.QueryUser(ctx, id) // 注意传入 ctx 控制超时
return u, err
})
if err != nil {
return nil, err
}
return v.(</em>User), nil
}当 singleflight.Group 不够用时：自定义合并策略的三个关键点
标准 singleflight 只支持“单 key 单次执行”，无法处理需要批量聚合的场景（例如 5 个不同 id 同时到来，希望合并为一次 SELECT * FROM user WHERE id IN (1,2,3,4,5)）。此时需自行实现，但必须守住三条底线：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
-
合并窗口必须有明确截止条件：不能只靠 time.Sleep，要用
time.AfterFunc或context.WithTimeout触发兜底提交，否则高并发下积压请求会拖垮内存 -
key 分组逻辑必须幂等且无歧义：例如按 URL path 分组时，要 normalize query 参数顺序（
a=1&b=2和b=2&a=1应视为同一 key），否则合并率归零 -
结果分发必须线程安全且不遗漏：每个原始请求对应一个
chan Result，不能共用 channel；写入前需检查 receiver 是否已取消（用select { case ch 避免 goroutine 挂起）
性能与边界：合并窗口设多少毫秒才合理
没有通用最优值。窗口过短（如 1ms），CPU 花费在频繁锁竞争和 channel 切换上，实际合并率低于 20%；窗口过长（如 100ms），用户感知延迟明显升高。建议从 5–10ms 起步，在生产环境用 p95 延迟 + 合并率双指标调优。
- HTTP 场景下，可结合
net/http.RoundTripper在 Transport 层做合并，但要注意 TLS 握手、连接复用等底层行为可能干扰 key 一致性 - 对强一致要求的写操作（如
POST /order），禁止合并——每个请求必须独立落库，否则会丢失业务语义 -
singleflight的内存占用与活跃 key 数正相关，长期运行服务需定期清理冷 key（例如用 LRU cache 包裹singleflight.Group）
最易被忽略的是：合并后的批量 SQL 查询，如果其中某个 ID 不存在，是返回空结果集，还是返回部分结果 + 错误？这个语义必须和上游协议对齐，否则前端拿到 []*User 却不知道哪个 ID 查无结果。
