rate.Limiter 不能控制并发数，因其设计目标是限 QPS 而非 goroutine 数量；它基于令牌桶，不感知 goroutine 生命周期，瞬时并发仍可能打爆下游。
为什么不能直接用 rate.Limiter 控制并发数
rate.Limiter 的设计目标是控制「单位时间请求数」（QPS），不是「同时运行的 goroutine 数量」。它基于令牌桶，只看请求到达时间戳，不感知 goroutine 生命周期。比如你设了 rate.Every(100 * time.Millisecond), 5，100 个 goroutine 同时调 Allow()，前 5 个立刻通过——瞬时并发照样爆表，下游照样被打挂。
常见误用现象：压测时 CPU 占用不高，但 DB 连接池打满、延迟毛刺剧烈、超时陡增。这不是限流器“没生效”，而是它根本没在控并发。
- 真正控并发，得靠信号量语义：要么拿令牌才能启动，用完必须归还
-
chan struct{}是最轻量、零依赖、调度开销最小的选择 - 别指望
rate.Limiter的burst参数来模拟并发限制——它只是允许透支的令牌数，不是并发槽位
用高阶函数封装 chan struct{} 并发限流器
核心是把「取令牌 → 执行 → 归还」这个流程抽象成一个函数，让业务代码只关心逻辑本身，不碰 channel 操作和 defer 管理。
示例实现：
立即学习“go语言免费学习笔记（深入）”；
func NewConcurrencyLimiter(n int) func(func()) {
sem := make(chan struct{}, n)
return func(fn func()) {
sem <- struct{}{} // 阻塞直到有空槽
go func() {
defer func() { <-sem }() // 必须确保归还，哪怕 panic
fn()
}()
}
}使用方式简洁：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
limit := NewConcurrencyLimiter(3)
for i := 0; i < 10; i++ {
limit(func() {
fmt.Printf("task %d starts\n", i)
time.Sleep(time.Second)
fmt.Printf("task %d done\n", i)
})
}- 返回的闭包是线程安全的，可复用、可传递、可组合
- 所有 goroutine 共享同一个
sem，天然满足“最多 n 个并发”语义 - panic 场景下仍能归还令牌，靠
defer+ 匿名 goroutine 保证 - 别在循环里重复调
NewConcurrencyLimiter，会创建多个互不干扰的信号量
如何让并发限流器“自适应”
自适应的关键不是动态改 channel 容量（做不到），而是根据实时负载信号，**动态替换限流器实例**，并让新旧实例平滑过渡。
你需要两个东西：
- 一个负载评估函数，例如：
func() float64，返回当前延迟 P95 或 CPU 使用率相对变化值 - 一个映射函数，例如：
func(load float64) int，把负载信号转成目标并发数（带上下限和阻尼）
然后用原子指针管理当前生效的限流器：
var limiter atomic.Value
limiter.Store(NewConcurrencyLimiter(10)) // 初始值
<p>// 每秒检查一次，按需更新
go func() {
ticker := time.NewTicker(time.Second)
defer ticker.Stop()
for range ticker.C {
load := getLoad() // 如：最近 10s 请求 P95 延迟
target := clamp(loadToN(load), 3, 20) // 下限 3，上限 20
limiter.Store(NewConcurrencyLimiter(target))
}
}()注意：旧 goroutine 可能还在用老的 limit 闭包，但没关系——它绑定的是旧的 sem，新请求走新的闭包，自然就切过去了。没有锁、没有竞争、无感切换。
- 别试图用
sync.Mutex锁住整个限流器再换，会成为性能瓶颈 - 不要在 handler 内部做 load 计算，采样必须前置、轻量、异步
- 阻尼很重要：若当前是 10，并检测到负载升高，别直接切到 3，建议每次最多调 20%（如 10→8→6）
容易被忽略的泄漏点和边界条件
最常出问题的地方不在算法，而在资源生命周期管理。
defer func() { 必须写在 goroutine 内部，不能写在外层函数里——否则归还时机错乱- 如果业务函数里启动了子 goroutine 且未等其结束就返回，令牌会被提前归还，导致并发失控
- channel 容量为 0 时，
sem 会永久阻塞；容量为 1 时，看似“串行”，实则因调度不确定性仍可能短暂并发 - 不要用
context.WithTimeout包裹限流器调用再期望自动取消——channel 阻塞不响应 cancel，得自己加 select 超时 - 测试时用
runtime.GOMAXPROCS(1)无法复现真实并发行为，要跑在多核上
真正难的不是写出限流逻辑，而是让“替换”这件事对正在运行的 goroutine 透明，又不让归还逻辑被绕过。这两点漏掉任意一个，都会在高负载下缓慢泄漏或突然雪崩。
