go time.After 优化
内容提要
Go 计时器优化要点：循环内复用 timer 应使用 NewTimer 加 Reset；Stop 返回 false 时需 drain channel，Go 1.23+ 可省略。Go 1.27 移除 asynctimerchan，新实现成为唯一行为。未 Stop 的 timer 虽可被 GC，但显式 Stop 仍是最佳实践；Ticker 必须 Stop，否则会持续触发造成泄漏。
延伸解读
Go 1.23+ 的 drain 逻辑：兼容与简化之间
文章指出，Go 1.23 之后 timer channel 变为同步，Stop/Reset 返回后不会再收到过期值，因此循环内复用 timer 时理论上可省略 drain 逻辑。但若代码库需兼容旧版本 Go，保留 drain 仍是更安全的写法。这提醒开发者：升级 Go 版本后，可评估是否移除冗余代码，但跨版本项目应优先保证行为一致。
显式 Stop 的价值：不只是防内存泄漏
即使 Go 1.23+ 未 Stop 的 timer 可被 GC 回收，文章仍建议显式 Stop。原因是 GC 回收并非立即释放，频繁创建 timer 而不 Stop 会持续占用运行时计时器堆，增加 GC 压力。显式 Stop 能让底层 timer 立刻从堆中摘除，属于更积极的资源管理习惯，与“会不会泄漏”是两个层面的问题。
Ticker 必须 Stop：与 GC 无关的硬性要求
文章特别强调 Ticker 与一次性 Timer 不同。只要 Ticker 还被存活的 goroutine 引用，它就是可达的，GC 不会回收，会持续触发并浪费 CPU 唤醒和调度开销。因此不 Stop 就是真正的资源泄漏，且与 Go 版本无关。使用 Ticker 时应始终 defer Stop，避免无限期运行。
AfterFunc 的 Stop：功能正确性优先
对于 time.AfterFunc，文章指出 Stop 直接影响程序逻辑：若想在某个条件下取消回调执行，必须调用 Stop。这与内存回收无关，而是功能正确性问题。开发者需区分“资源管理”与“逻辑取消”两种场景，不能因新版本 GC 优化而忽略 AfterFunc 的 Stop 调用。
Q&A
在 Go 中循环复用 timer 时，为什么推荐使用 NewTimer 加 Reset 而不是 time.After？
因为 time.After 每次调用都会创建一个新的 timer，在循环中会导致大量 timer 对象产生，增加 GC 压力。而 NewTimer 加 Reset 可以复用同一个 timer，避免重复创建，更高效。
Go 1.23 之后，timer.Stop() 返回 false 时还需要手动 drain channel 吗？
在 Go 1.23+ 中，timer channel 是同步的，Stop/Reset 返回后能保证不会再收到过期值，因此理论上可以省略 drain 逻辑。但如果需要兼容旧版本 Go，保留 drain 逻辑更安全。
Go 1.27 对计时器实现做了哪些改变？
Go 1.27 移除了 asynctimerchan 这个 GODEBUG 开关，使得 Go 1.23 引入的新计时器实现（可被 GC 回收 + 同步 channel）成为唯一行为，不再有回退旧实现的选项。
未 Stop 的 timer 会被 GC 回收吗？还需要显式调用 Stop 吗？
未 Stop 的 timer 最终会被 GC 回收，但显式 Stop 仍是最佳实践，因为它能让底层 timer 立刻从运行时的堆里摘除，而不是等 GC 扫描到，从而减少内存占用和 GC 压力。
为什么 Ticker 必须调用 Stop？不 Stop 会有什么后果？
Ticker 会持续触发，只要它还被某个存活的 goroutine 引用，GC 就不会回收它，会一直触发下去，浪费 CPU 唤醒和调度开销。因此必须显式调用 Stop，否则会导致真正的资源泄漏。
在 Go 1.27 中，time.After 在 select 里被跳过还会导致内存泄漏吗？
不会。Go 1.27 把“未 Stop 的 timer/ticker 不会造成内存泄漏”变成了语言运行时的永久保证，因此不再需要担心 time.After 在 select 里被跳过导致的经典泄漏。但 Ticker 仍然必须 Stop。
