time.newtimer创建后立即开始计时，倒计时与是否读取timer.c无关，stop不清理已写入通道的值，time.after是不可停止的封装。
time.NewTimer 创建后立即开始计时
调用 time.NewTimer 的瞬间，计时器就已启动，不是“创建完再手动触发”。它内部绑定一个 goroutine 和系统级定时器资源，一旦创建，倒计时就开始跑，和后续是否读 timer.C 无关。
常见错误现象：在 time.NewTimer(5 * time.Second) 后加了 time.Sleep(1 * time.Second)，以为“延迟启动”，其实只是主线程暂停，定时器仍在后台倒数——5 秒总时长不会因此变长。
- 计时精度依赖系统调度，通常误差在几毫秒内，但不保证绝对精确（尤其在高负载或 GC 期间）
- 如果创建后没读
timer.C，到期信号会一直堵在通道里，直到有人读取；若 timer 已 Stop，该信号仍可能被后续读到（见下文） -
time.After是time.NewTimer(d).C的封装，但无法 Stop，适合简单单次等待场景
Stop 之后必须消费或丢弃 C 通道残留值
timer.Stop() 只取消未触发的定时，**不清理已写入 timer.C 的值**。如果定时器刚好在 Stop 前触发，timer.C 已有值，Stop 返回 false，但通道里那个时间还在。
典型坑：Stop 后直接 close(timer.C) 或忽略通道，然后 elsewhere 读 → panic: send on closed channel 或死锁。
- 安全做法：Stop 后用
select非阻塞读一次：select { case - 更严谨场景（如复用 timer）：Stop 后循环清空，但仅限确认无其他 goroutine 往该通道写入时使用：
for len(timer.C) > 0 { - 如果 timer 已触发且你没读过
timer.C，Stop()返回false，此时应主动读一次再处理逻辑
Reset 不等于 Stop + NewTimer，且不能对已触发的 timer 直接 Reset
timer.Reset(d) 是原子操作：先尝试 Stop 当前 timer，再以新 duration 重启。但它**只对未触发的 timer 生效**；如果 timer 已触发（timer.C 已有值），Reset 返回 false，且不会重置计时器。
常见误用：创建 timer → 忘记读 timer.C → 过期后调 Reset → 无效，因为 timer 实际已进入“已触发”状态。
- Reset 前务必确保
timer.C已被读空，否则行为不可控 - Reset 与 Stop 都返回 bool，建议始终检查返回值，而不是假设成功
- 不要把 Reset 当作“重新初始化”，它不释放旧资源；频繁 Reset 比 Stop+NewTimer 更轻量，但逻辑更易出错
超时控制中 timer 和 context.WithTimeout 的选择
网络请求、IO 等超时场景，优先用 context.WithTimeout，而不是手撸 time.NewTimer。前者能自动 cancel 子 goroutine、传播取消信号、与 select 集成自然；后者需手动管理 Stop/Reset/通道读取，容易漏掉 cleanup。
- 用
context.WithTimeout：支持 cancel、deadline、Done() 通道统一接入，标准库函数（如http.Client.Do）原生支持 - 用
time.NewTimer：适合纯时间驱动的独立逻辑，比如“3 秒后发心跳”“5 秒后重试”，且不涉及上下文取消链路 - 混合用法常见：用 timer 控制单次动作，用 context 控制整个请求生命周期 —— 两者不互斥，但职责要分清
真正难的不是调用 time.NewTimer，而是判断什么时候该 Stop、要不要 Reset、以及如何安全地从 timer.C 拿到那个时间点 —— 尤其当多个 goroutine 可能同时操作同一个 timer 时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
