channel限流本质是控制并发数而非QPS，通过chan struct{}限制同时运行的goroutine数量，不感知时间窗口或请求数，适合下游调用与批量任务，不适合毫秒级速率限制。
channel 做限流，本质是控制并发数，不是控制 QPS
用 chan struct{} 实现的限流，实际只是限制同时运行的 goroutine 数量，比如最多 5 个请求并行处理。它不感知时间窗口、不统计请求数、也不自动重置——和 Redis + Lua 那种“100 次/秒”完全不同。
- 适合：后端服务调用下游 API、批量任务并发控制、避免 goroutine 泛滥
- 不适合：需要精确到毫秒级速率限制（如每秒最多 200 次 HTTP 请求）
- 注意：
make(chan struct{}, N)的N是缓冲区大小，不是“令牌总数”，别误以为能存 N 个“令牌”再消费
最简可用的 channel 限流写法
核心就是“取 token → 执行 → 归还 token”，用空结构体 channel 最省内存：
var limitCh = make(chan struct{}, 5)
<p>func doWork() {
limitCh <- struct{}{} // 阻塞直到有空位
defer func() { <-limitCh }() // 一定要放 defer，否则 panic 或 return 早了会漏归还</p><pre class='brush:php;toolbar:false;'>// 实际业务逻辑
time.Sleep(100 * time.Millisecond)}
- 必须用
defer归还，不然 goroutine 泄漏或后续调用永久阻塞 - 别在
select里加default走非阻塞逻辑——那就不叫限流了，是“尽力而为” - 如果业务可能 panic，
defer仍有效；但若用recover后提前 return，要确保已执行
为什么不用 buffered channel 模拟令牌桶？
有人试过 make(chan time.Time, cap) 存时间戳、或者用 len(ch) 判断剩余额度，这些都不可靠：
立即学习“go语言免费学习笔记（深入）”；
-
len(ch)返回的是当前缓冲区已写入但未读取的数量，不是“剩余配额”——因为没人保证每次只取一个、也不保证归还时机一致 - channel 不是锁，无法原子地“检查 + 占用”，
len(ch) > 0和之间存在竞态 - 想实现令牌桶或漏桶，该用
golang.org/x/time/rate.Limiter，它底层用 mutex + 时间计算，channel 并不适合这类场景
goroutine 泄漏是最常见的坑
限流代码写错，最容易导致整个服务慢慢卡死——表现是 goroutine 数持续上涨，runtime.NumGoroutine() 越来越高，但 CPU 不高、请求变慢：
- 忘记
defer归还：函数中途 return 或 panic，没执行 - 把
limitCh声明在局部作用域（比如某次 HTTP handler 里），导致每次新建 channel，旧的永远没人关 - 用
close(limitCh)想“清空”，结果所有阻塞的 `
上线前建议加一行日志：log.Printf("active goroutines: %d", runtime.NumGoroutine())，观察压测时是否线性增长。
