time.newtimer 不会主动阻塞 goroutine，但必须显式读取 timer.c 才能感知超时，否则定时器泄漏；需配合 select 使用，及时调用 stop() 防止内存泄漏。
time.NewTimer 会阻塞 goroutine 吗
不会主动阻塞，但 <strong>timer.C</strong> 是一个只读的 chan time.Time，直接从它接收（）会阻塞，直到定时器触发或被停止。这是最常见误用点：有人以为 <code>time.NewTimer 启动后就“自动执行”，其实它只是创建并启动了一个后台计时器，你必须显式监听通道才能感知超时。
典型错误写法：
timer := time.NewTimer(2 * time.Second) // 忘了读取 timer.C，timer 在后台跑完就泄漏了 // 下次再用 timer.C 会 panic: send on closed channel
- 必须用
或 <code>select配合case 消费信号 - 如果提前调用
timer.Stop()，对应通道不会关闭，但后续读取会永久阻塞——所以Stop()后不能再读timer.C - 想安全重用？别重用，
time.NewTimer本就是一次性的；需要重复超时，用time.AfterFunc或循环新建
超时控制必须配合 select 使用
单独用 只能等超时，没法和业务逻辑并发协作。真正有用的超时控制，几乎总是出现在 <code>select 语句里。
比如发起 HTTP 请求并限制 3 秒：
timer := time.NewTimer(3 * time.Second)
defer timer.Stop() // 防止 goroutine 泄漏
<p>client := &http.Client{Timeout: 10 * time.Second}
resp, err := client.Get("<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>")</p><p>select {
case </p><p>if err != nil {
return err
}
return processResponse(resp)</p>
-
select的default分支让逻辑非阻塞——但这里容易错：如果把client.Get放在select外，它本身可能卡住十几秒，超时就失效了 - 更稳妥的是把耗时操作也放进
select，例如用make(chan result, 1)包装异步请求 -
timer.Stop()必须调用，否则即使超时未发生，timer 对象也不会被 GC，长期运行会累积内存
time.NewTimer 和 time.After 的区别在哪
两者都返回 ，但底层行为不同：<code>time.After(d) 是 time.NewTimer(d).C 的封装，但它不暴露 Timer 实例，无法调用 Stop()。
- 短生命周期、确定不会提前取消的场景（如简单延时日志），用
time.After更简洁 - 需要主动取消（比如用户中途取消请求）、或需复用/检查是否已触发的，必须用
time.NewTimer - 性能上无差异，但
time.After创建的 timer 无法 Stop，超时前 GC 不会回收其底层资源 - 别这么写：
select { case —— 每次 select 都新建 timer，泄漏风险高
为什么 timer.Stop() 返回 bool，什么时候是 false
timer.Stop() 返回 bool 表示“是否成功停止”：true 代表 timer 尚未触发，被成功取消；false 代表 timer 已经触发或正在向 timer.C 发送时间值，此时停止失败。
- 返回 false 并不危险，只是说明超时已经发生，你该按超时路径处理了
- 常见误判：看到
!timer.Stop()就 panic 或跳过清理——其实可以忽略，只要确保不重复读timer.C即可 - 安全模式：总是先
select尝试接收，再Stop()，避免竞态 - 注意：
Stop()后不能再读timer.C，否则永远阻塞；但已触发的发送不会被撤回，所以select中仍可能命中分支
超时控制真正的复杂点不在 API 调用，而在业务逻辑与 timer 生命周期的耦合——比如网络请求中，是停掉连接、还是忽略响应、还是允许部分数据到达，这些决策没法靠 time.NewTimer 自动完成。
