不能用 time.ticker 实现令牌桶，因其仅支持固定节奏发放令牌，无容量限制与预存能力；真正的令牌桶需支持突发流量缓冲、恒定填充速率及超限拒绝，故须自行维护带容量和时间戳的状态。
为什么不用 time.Ticker 做令牌桶？
直接用 time.Ticker 模拟“每秒放一个令牌”看似简单，但会漏掉突发流量的缓冲能力——它本质是固定节奏的生产者，没有容量概念，也不支持预存令牌。真正的令牌桶必须能：允许短时爆发（桶没空）、限制长期平均速率（填充速率恒定）、拒绝超限请求（取令牌失败）。所以得自己维护一个带容量和时间戳的状态。
用 chan struct{} 实现最小可行令牌桶
channel 本身不能“存数字”，但可以用它做信号队列：每个 struct{} 代表一个可用令牌。关键在控制入队节奏和容量上限。
- 初始化时用
make(chan struct{}, capacity)创建带缓冲的 channel，容量即桶大小 - 启动一个 goroutine，按
time.Duration(1e9 / rate)（纳秒）周期向 channel 发送令牌，但只在未满时发：select { case ch - 取令牌用
select { case ，非阻塞判断 - 注意：不要用
len(ch)判断剩余令牌数——它不准确，因并发读写下值可能瞬变；始终以能否成功接收为准
time.Now() 和填充逻辑放哪？别在每次 Take() 里算
常见错误是每次调用 Take() 都算距上次填充过了多久、该补几个令牌——这既慢又难保证线程安全。正确做法是让填充 goroutine 独占状态更新，主逻辑只做原子收发。
- 填充 goroutine 里用
time.Sleep()或time.AfterFunc()控制间隔，避免忙等 - 如果填充速率很低（如每分钟 10 个），别用
time.Sleep()精确卡点，改用“每次填充后重算下次时间”，防止 drift 积累 - channel 缓冲区满时，填充 goroutine 应跳过本次发送，而不是阻塞——否则整个限流器会卡住
真实场景下必须加锁？不一定，但得看怎么用
纯 channel 方案在高并发下能跑，但有个隐藏前提：所有 Take() 调用都走同一个 channel 的 recv 操作，而 Go runtime 对 buffered channel 的 send/recv 是原子的。所以只要不额外读写共享变量（比如记录 lastFillTime），就无需显式锁。
- 如果需要精确统计剩余令牌数、或支持动态调整速率/容量，则必须引入
sync.Mutex或atomic变量 - 用
sync.Pool复用 token 结构体毫无意义——struct{}零开销，且 channel 内部不分配堆内存 - 测试时别用
runtime.Gosched()模拟并发，直接起 100+ goroutine 并发调Take()更靠谱
真正难的是把填充节奏和请求响应耦合对齐——比如填充间隔设成 100ms，但某次网络延迟导致连续 3 个请求在 5ms 内到达，这时桶是否该允许全过？答案取决于你填的是“固定速率”还是“平滑速率”。大多数业务要的是后者，那就得换更稳的实现，比如基于 time.Now() + atomic 的滑动窗口式令牌桶。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
