Go中防抖需用time.AfterFunc和sync.Mutex组合实现：每次调用取消旧定时器并重设新定时器，用Mutex保护timer指针和运行状态，Reset失败时须新建Timer，避免阻塞和竞态。
防抖在 Go 中怎么用 time.AfterFunc 和 sync.Mutex 控制单次触发
Go 本身不提供开箱即用的防抖（debounce）原语，得靠自己组合定时器和状态锁。核心逻辑是：每次调用时取消旧定时器、重设新定时器，确保只执行最后一次触发后的回调。
常见错误是直接复用 time.Timer 而不检查 Reset() 返回值——如果 Timer 已过期或已停止，Reset() 会返回 false，此时必须新建一个 Timer，否则调用会丢失。
- 用
sync.Mutex保护*time.Timer指针和是否正在运行的状态，避免并发调用导致 panic 或竞态 - 不要用
time.Sleep模拟延迟，它会阻塞 goroutine；必须用time.AfterFunc或Timer.C配合 select 实现非阻塞 - 防抖函数应接收
func()类型回调，而不是返回 channel——channel 容易堆积未消费信号，违背“只执行最后一次”的语义
func NewDebouncer(delay time.Duration) *Debouncer {
return &Debouncer{
delay: delay,
timer: time.NewTimer(delay),
}
}
type Debouncer struct {
delay time.Duration
mu sync.Mutex
timer *time.Timer
fn func()
}
func (d *Debouncer) Call(f func()) {
d.mu.Lock()
defer d.mu.Unlock()
if d.timer != nil {
if !d.timer.Stop() {
select {
case <-d.timer.C:
default:
}
}
}
d.fn = f
d.timer = time.AfterFunc(d.delay, func() {
d.mu.Lock()
f := d.fn
d.fn = nil
d.mu.Unlock()
if f != nil {
f()
}
})
}
限流选 golang.org/x/time/rate 还是手写 token bucket
官方 rate.Limiter 就是 token bucket 实现，稳定、压测过、支持 burst 和 rate 动态调整，没理由自己重写。但要注意它默认用 time.Now()，在测试中难 mock；生产中若系统时间被 NTP 调整，可能造成瞬时放行过多（因 tokens 累积逻辑依赖时间差）。
典型误用是把 limiter.Wait() 放在 HTTP handler 最外层，却没考虑超时控制——它会无限等待直到拿到 token，导致请求 hang 死。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 总是配合
context.WithTimeout使用limiter.Wait，例如limiter.Wait(ctx)，而非裸调用 - burst 值不要设为 0：设为 0 时
Allow()永远返回 false，Reserve()也拿不到可用 token - 如果需要 per-user 限流，别共享一个
rate.Limiter实例，应按 key 分片（如用sync.Map缓存 user → limiter），否则变成全局限流
防抖 + 限流组合时，哪个该前置、哪个该嵌套
顺序错了就失去意义：如果先限流再防抖，可能同一用户多次请求被限流器分别计数，但最终只执行一次——浪费配额；如果先防抖再限流，才能保证“合并后的一次执行”才消耗 token。
更关键的是资源归属：防抖的定时器属于单次调用上下文，而限流器通常是长生命周期对象。所以结构上，应让防抖包裹业务逻辑，再把整个防抖回调交给限流器调度。
- 不要在防抖回调里再起 goroutine 去调用限流器，这会绕过限流（因为限流判断发生在 goroutine 启动前）
- 如果防抖间隔内收到 10 次请求，理想行为是：只提交 1 次到限流器，且这次提交成功后才真正执行业务；失败则整个批次丢弃，不重试
- HTTP 场景下，建议把限流放在路由层（如 middleware），防抖放在业务逻辑内部——因为限流要覆盖所有入口，而防抖往往只针对特定操作（如保存草稿）
为什么 time.AfterFunc 比 time.Tick 更适合防抖
time.Tick 创建的是无缓冲的 ticker channel，每次触发都往里塞时间点。如果接收端没及时读，channel 会阻塞 ticker goroutine，最终导致内存泄漏和时间漂移。防抖不需要周期性触发，只需要“延迟后执行一次”，time.AfterFunc 天然契合这个语义，且无 channel 管理负担。
另一个坑是：用 time.After + select 实现防抖时，容易漏掉对 ctx.Done() 的监听，导致 cancel 后定时器还在跑。
-
time.AfterFunc返回的*Timer可以安全Stop()，而time.After返回的是不可控的 channel - 所有基于
time.AfterFunc的防抖实现，都必须在Stop()失败后清空Timer.C，否则残留值会干扰下一次AfterFunc执行 - 别为了“统一风格”强行把防抖和限流都改成 channel-based——channel 适合扇出/扇入，不适合精确控制单次延迟执行
Stop() 是否总被执行、Wait(ctx) 是否带超时、以及 sync.Mutex 是否锁住了所有可变状态。 
