Golang如何实现一个高并发下的请求合并函数？SingleFlight库详解【详解】-Golang-PHP中文网

singleflight.group.do 能解决重复请求问题，因为它对相同 key 仅执行一次函数，其余请求共享结果；而 sync.map 和 channel 无法阻塞等待，缺乏“共享执行权”。

golang如何实现一个高并发下的请求合并函数？singleflight库详解【详解】

为什么直接用 sync.Map 或 channel 无法解决重复请求问题

并发场景下，多个 goroutine 同时发起相同参数的请求（比如查同一个 user_id），若不做协调，后端服务会收到 N 次重复调用。sync.Map 只能缓存结果，不能阻塞后续请求等待首次调用完成；channel 手动编排容易陷入死锁或漏唤醒——关键缺的是「共享执行权」：同一组 key 的所有请求，只允许一个 goroutine 真正执行函数，其余必须等待其返回。

singleflight.Group.Do 的行为与典型误用

singleflight.Group.Do 是标准库 golang.org/x/sync/singleflight 提供的核心方法，它不是缓存工具，而是「执行协调器」：对相同 key，仅首个调用者触发 fn，其余调用者挂起并共享该次执行结果（含 error）。常见错误包括：

把 Do 当成带过期的缓存用（它不清理 key，也不支持 TTL）
在 fn 内部又调用 Do 相同 key（可能造成递归等待或 panic）
忽略 v, shared, err := g.Do(key, fn) 中的 shared 返回值，误以为每次都是新执行

示例：防止重复加载配置

var configGroup singleflight.Group

func LoadConfig(cfgID string) (map[string]string, error) {
	v, _, err := configGroup.Do(cfgID, func() (interface{}, error) {
		return fetchFromDB(cfgID) // 真实耗时操作
	})
	if err != nil {
		return nil, err
	}
	return v.(map[string]string), nil
}

如何处理 panic、超时和取消

singleflight 本身不处理 context 取消或 panic 恢复，需手动包裹：

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

panic：在 fn 内用 defer/recover，否则整个 group 会卡死（panic 不传播给其他等待者，但未完成的等待不会被唤醒）
超时/取消：必须在 fn 内检查 ctx.Done()，Do 不感知外部 context
不要在 fn 中直接传入带 cancel 的 context 并调用 http.NewRequestWithContext 等——cancel 会影响所有共享该 key 的请求

安全写法示例：

func LoadWithCtx(ctx context.Context, key string) (string, error) {
	v, _, err := configGroup.Do(key, func() (interface{}, error) {
		// fn 内部新建子 context，避免影响其他等待者
		subCtx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
		defer cancel()
		
		select {
		case 

<h3>合并失败后是否重试？要不要加 fallback 缓存？</h3>
<p><code>singleflight</code> 对失败的执行结果照常广播给所有等待者，不会自动重试。是否重试取决于业务逻辑——比如下游临时不可用，你可能希望稍后重试；但如果是参数错误，重试无意义。更关键的是：它不提供 fallback 缓存，一旦首次执行失败，所有请求都拿到 error。所以实际使用中通常要组合 <code>sync.Map</code> 或 <code>ristretto</code>：</p>