sync.Mutex不能当信号量用，因其仅支持单并发互斥，而信号量需N级许可控制；正确做法是用golang.org/x/sync/semaphore等带计数与上下文感知的许可池。
为什么 sync.Mutex 不能当信号量用
因为 sync.Mutex 是互斥锁，只允许一个 goroutine 进入；而信号量需要支持 N 个并发许可。直接拿 Mutex 做限流，要么卡死（比如想限 5 并发却只放行 1 个），要么根本不起作用（靠业务层自己数计数器，容易竞态）。
常见错误现象：panic: sync: negative WaitGroup counter 或爬虫突然全速冲垮目标站——本质是把“许可获取/释放”逻辑写散了，没原子性保障。
- 真正要用的不是锁，是带计数的、可阻塞的许可池
-
semaphore的核心语义是：申请成功就扣减，释放就归还，超限时自动排队 - Golang 标准库没内置信号量，得靠
sync.WaitGroup+chan struct{}或第三方如golang.org/x/sync/semaphore
用 golang.org/x/sync/semaphore 控制并发请先看这三点
这个包是官方维护的，稳定且轻量，但默认行为和直觉有偏差，不注意会漏控或假限流。
-
semaphore.NewWeighted(5)中的5是最大并发数，不是初始可用数；它本身不记录“已用”，只管当前有没有空位 - 必须显式调用
Acquire(ctx, 1)才能拿许可，失败时返回 error（比如 ctx 超时），**不检查 error 就等于没限流** - 释放必须配对调用
Release(1)，且参数要和Acquire的 weight 一致；Release(2)会导致后续Acquire多放出两个许可，彻底失控
示例片段：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
sem := semaphore.NewWeighted(3)
for _, url := range urls {
if err := sem.Acquire(ctx, 1); err != nil {
log.Printf("acquire failed: %v", err)
continue
}
go func(u string) {
defer sem.Release(1) // 必须在这儿还，不能在外部统一收口
fetch(u)
}(url)
}不用第三方包时，用 chan struct{} 自建信号量的坑
很多人用 make(chan struct{}, 3) 模拟信号量，简单但危险：channel 容量固定，len(ch) 不可靠（非原子），且无法感知上下文取消。
- 发送前不加
select { case ch ，可能永久阻塞 goroutine - 接收端用
<-ch释放，但如果某次 panic 没走到这步，许可就永远泄露 - 没有超时机制，一个卡住的请求会让整个池子停摆
- 如果爬虫任务本身耗时差异大，这种静态 channel 容易造成“许可闲置”（比如 2 个慢任务占着 3 个 slot，剩下 10 个快任务干等）
ctx.WithTimeout 和信号量组合时最容易忘的一件事
给 Acquire 传的 ctx，不能复用主流程的 long-lived ctx。否则一旦主 ctx cancel，所有等待中的 acquire 都会立刻失败，导致大量请求被丢弃，而不是平滑降级。
- 每个爬取任务应派生自己的短 timeout ctx：
childCtx, _ := context.WithTimeout(ctx, 10*time.Second) - 不要把信号量池放在 handler 里反复创建——它要复用，生命周期应覆盖整个爬取批次
- 如果目标站响应慢，优先调小单次 timeout，而不是调大信号量值；后者只是掩盖问题，反而加剧雪崩
真正难的不是写对那几行 acquire/release，而是把“许可生命周期”和“业务任务生命周期”严丝合缝地对齐。少一个 defer，错一个 ctx，漏一次 Release，速率控制就形同虚设。
