goroutine泄漏比cpu跑满更常见，需用semaphore控并发数、token bucket控速率；错误复用或未释放会导致oom或阻塞，应分层混合使用并监控。
goroutine 泄漏比跑满 CPU 更常见
不限制 goroutine 数量，程序往往不是卡死，而是悄无声息地吃光内存、触发 OOM Kill，或者在高并发下因调度开销陡增而响应变慢。这不是“要不要限”的问题，而是“不加控制就一定会出事”。
真正要选的，是用 semaphore（信号量）还是 token bucket（令牌桶）——前者管“并发数”，后者管“速率”。别被名字吓住，它们解决的是两类不同问题：
-
semaphore：适合你明确知道“最多同时处理 10 个请求”这种场景，比如调第三方 API 有连接池限制 -
token bucket：适合你关心“每秒最多发 100 次请求”这种节奏控制，比如防刷、配额管理
用 golang.org/x/sync/semaphore 控制并发上限
这是最轻量、最直接的方式，底层就是带计数的 channel + mutex，没魔法，也几乎没性能损耗。
常见错误是把 semaphore 当成全局变量反复复用却忘了 Acquire 后必须 Release，一旦 panic 或提前 return，就会永久占着一个 slot，最终所有 goroutine 都在 Acquire 处阻塞。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 按业务边界初始化，比如每个 HTTP handler 用独立
*semaphore.Weighted，避免跨服务干扰 - 用
defer sem.Release(1)包裹整个逻辑块，而不是只包关键段——哪怕中间有return或panic也能释放 - 不要设过小的
max值（比如 1），它会把并发压成串行，反而放大延迟；通常从 5–50 开始试，结合 p95 响应时间和runtime.NumGoroutine()观察调整
示例片段：
sem := semaphore.NewWeighted(10)
err := sem.Acquire(ctx, 1)
if err != nil {
return err
}
defer sem.Release(1)
// ... 执行实际工作
用 golang.org/x/time/rate 实现请求速率控制
rate.Limiter 是标准库里最常被误用的组件之一：很多人以为它能“限制 goroutine 数量”，其实它只控制“事件发生频率”，和 goroutine 生命周期无关。你仍可能瞬间起 1000 个 goroutine，只是其中 990 个会在 Wait 或 Allow 时被阻塞或拒绝。
典型误用场景：用 rate.NewLimiter(10, 10) 试图限制并发数，结果发现 QPS 上去了，并发数还是爆表。
实操建议：
- 参数含义要盯紧：
rate.Limit是每秒多少次，burst是允许突发多少次——它不是最大并发数，而是“最多积压多少次请求等你处理” - 配合上下文使用：
limiter.Wait(ctx)会阻塞，limiter.Allow()返回 bool，选哪个取决于你希望失败快还是等一等 - 注意时钟精度：
rate.Limiter依赖系统单调时钟，短于 10ms 的burst可能不敏感，别指望它做毫秒级精确节流
混合用法：先控速率再控并发
真实后端服务往往既要“每秒最多 100 次调用”，又要“同一时刻最多 5 个并发调用第三方”。这时候单靠 rate.Limiter 或单靠 semaphore 都不够。
正确姿势是分层：外层用 rate.Limiter 拦掉超速流量，内层用 semaphore 防止下游被打垮。两者不冲突，但顺序不能反——如果先抢信号量再限速，burst 流量仍可能瞬间打满并发槽位。
容易忽略的点：
-
rate.Limiter的burst值如果远大于semaphore的max，会导致大量 goroutine 卡在semaphore.Acquire等待，堆积大量 goroutine，内存悄悄涨 - 别在循环里重复创建
rate.NewLimiter或semaphore.NewWeighted，它们不是一次性的，复用才是常态 - 监控一定要跟上：
semaphore.CurrentCount()和rate.Limiter.ReserveN返回的time.Until都可暴露为指标，否则你永远不知道限流是不是真在起作用
事情说清了就结束。
