Go中防抖函数的核心逻辑是每次新调用都取消前一次未触发的定时任务，只保留最后一次调用后的延迟执行，关键依赖time.Timer的Stop()和Reset()方法实现可取消的重置计时，而非新建Timer或使用不可取消的time.AfterFunc。
Go 中防抖函数的核心逻辑是什么
防抖不是简单地用 time.Sleep 延后执行，而是「重置计时器」：每次新调用都取消前一次未触发的定时任务，只保留最后一次调用后的延迟执行。关键在于用 time.Timer 的 Reset() 方法，而不是反复新建 Timer —— 否则会泄漏 goroutine 和 timer 资源。
常见错误是直接在闭包里启动 time.AfterFunc，导致每次调用都新建一个 timer，无法取消旧任务；或者用 select + time.After 但没处理已存在的 channel 接收，造成 goroutine 阻塞。
一个安全可复用的 Debounce 函数怎么写
推荐封装成接受函数、延迟毫秒数、返回可取消的触发器。内部用指针保存当前 *time.Timer，每次调用先 Stop()（安全，可重复调用），再 Reset() 新时间。
- 必须用指针保存 timer，否则值拷贝会导致
Stop()失效 - 延迟时间用
time.Duration类型传入，避免硬编码time.Millisecond换算 - 返回一个
func()触发器，方便绑定事件（比如 HTTP 请求、文件变更通知） - 额外提供
Cancel()方法清理资源，尤其在 long-running service 中必须调用
func NewDebounce(fn func(), delay time.Duration) (trigger func(), cancel func()) {
var timer *time.Timer
mu := sync.Mutex{}
<pre class="brush:php;toolbar:false;">trigger = func() {
mu.Lock()
if timer != nil {
timer.Stop()
}
timer = time.AfterFunc(delay, fn)
mu.Unlock()
}
cancel = func() {
mu.Lock()
if timer != nil {
timer.Stop()
}
mu.Unlock()
}
return trigger, cancel}
为什么不能直接用 time.AfterFunc 做防抖
time.AfterFunc 返回的是无状态的 timer，一旦启动就无法从外部干预；而防抖需要「取消上一次」的能力。如果每次调用都新建 time.AfterFunc，旧 timer 仍会在后台运行，直到超时才触发 —— 这就违背了防抖语义，还可能引发竞态或 panic（比如 fn 访问已释放的资源）。
典型错误现象：panic: send on closed channel 或者回调被意外多次执行，尤其在高频事件（如 resize、input 输入）下明显。
- 不加锁时，并发调用
trigger()可能同时操作timer指针，导致nil pointer dereference - 忘记调用
Stop()，timer 不会被 GC，长期运行的服务内存缓慢上涨 - 把
delay写成100而不是100 * time.Millisecond，单位错导致延迟长达 100 秒
实际使用时要注意哪些边界场景
防抖不是万能的，它天然丢弃中间状态 —— 如果你需要记录每次输入（比如搜索建议要反映最新关键词），就不能只靠防抖，得配合节流或手动缓存最新参数。
- 函数
fn若含 panic，不会传播到调用方，需在fn内部 recover - 如果
fn执行耗时超过delay，下一次触发会叠加延后（即「防抖窗口」始终从最后一次调用起算，不是固定周期） - 测试时别用
time.Sleep等待，改用testutil.Wait或time.After+ channel select，避免 flaky - 在 http handler 里使用，注意 request context 取消时应同步
cancel()，否则 goroutine 泄漏
最常被忽略的是：防抖对象生命周期和所属组件不一致时，比如在 struct 方法里创建 debounce，但 struct 被回收后 timer 还活着 —— 必须显式调用 cancel，不能依赖 GC。
