Go 1.21+ 应用 sync.Semaphore 实现自适应并发控制，需配合空闲超时与外部反馈：信号量仅负责硬限流，容量作为可变参数由 ticker 和计数器动态调整，缩容须等待空闲窗口、扩容依据 acquire 阻塞频次，所有 acquire/release 必须配对且 panic 安全，限流点须落在业务实际执行前（如 client.Do 前）。
用 sync.Semaphore + 空闲超时实现自适应并发控制
Go 1.21+ 标准库的 sync.Semaphore 是唯一推荐的底层原语，但它本身不带“伸缩”逻辑——自适应必须靠外部反馈控制。核心思路是：把信号量容量当作可变参数，配合空闲检测器（ticker + 计数器）动态调整。
-
sem只负责硬性限流（acquire/release），不管理 goroutine 生命周期 - 真正“自愈”体现在：当连续 N 秒无任务 acquire 成功时，主动缩小
sem容量；当新任务涌入导致 acquire 频繁阻塞时，再逐步扩大 - 调整不能太激进：每次只 ±1 或 ±2，避免抖动；最小值建议设为 1，最大值由资源上限决定（如 CPU 核心数 × 4）
- 所有调整操作必须加锁（
sync.RWMutex），且读写分离：acquire 时只读容量，调整时才写
反馈控制算法的关键变量与触发条件
这不是 PID 控制，而是轻量级事件驱动反馈：只依赖两个可观测指标——任务到达速率和空闲持续时间。不需要预测模型，也不依赖 pprof 或 runtime.NumGoroutine() 这类采样数据（它们滞后且不准）。
-
空闲判定：用
time.AfterFunc或 ticker 检测“最近一次 acquire 成功后是否超过阈值（如 30s）”，不是检测 goroutine 是否存活 -
扩容触发：当
sem.Acquire返回context.DeadlineExceeded的次数在 10s 内 ≥ 3 次，说明当前容量已成瓶颈 -
缩容安全边界：缩容前检查当前已 acquire 的数量（
sem.Len()不可用！得自己维护计数器），确保不会把正在运行的任务卡住 -
上下文一致性：所有
Acquire必须传入同一个ctx，且该ctx应带超时（如context.WithTimeout(ctx, 5*time.Second)），否则扩容判断会失效
容易被忽略的 panic 安全释放细节
很多人用 defer sem.Release(1) 却没意识到：如果 Acquire 失败（比如 context canceled），就不该调用 Release —— 否则会 panic：panic: semaphore: negative count。
- 正确模式是：
if err := sem.Acquire(ctx, 1); err != nil { return err }，然后才defer sem.Release(1) - 绝不能把
sem.Release(1)放在Acquire失败分支里，更不能裸写sem.Release(1)而不配defer - 如果业务逻辑里有多个
return点，defer位置必须在函数入口处，否则中间 panic 会导致漏释放 - 别用
len(semChan)判断剩余容量——它返回已占用数，不是可用数；sync.Semaphore也没有公开的 len 方法，得自己维护
HTTP 客户端场景下的典型错误位置
限流必须卡在真正发起网络请求前一刻，而不是 goroutine 启动时或循环体外。否则看似并发数可控，实际 TCP 连接数早已爆表。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
for _, url := range urls { go fetch(url) }，然后在fetch函数开头sem.Acquire—— 这会导致大量 goroutine 堆积等待，内存飙升 - 正确写法：在
http.NewRequest之后、client.Do之前调用sem.Acquire，失败直接 return，绝不让请求发出 - 即使
client.Do返回 error（如 timeout、connection refused），也必须执行defer sem.Release(1)，因为许可已经获取成功 - 别碰
http.Transport.MaxIdleConnsPerHost——那是连接复用策略，和并发请求数无关；也别对整个*http.Client加锁
