短轮询必须用time.Ticker而非time.Sleep：Ticker精度高、GC压力小、支持select控制；Sleep误差大、goroutine调度开销高；须Stop防泄漏，HTTP请求需context超时兜底，状态更新须原子或加锁。
短轮询必须用 time.Ticker，别用 time.Sleep 循环
用 time.Sleep 在 for 循环里做间隔等待，看似简单，但每次唤醒都需重新调度 goroutine，误差累积快、响应不稳，尤其在高并发或系统负载波动时，实际间隔可能漂移 50ms 以上。而 time.Ticker 是 Go 运行时原生支持的定时器，底层复用时间轮（timing wheel），精度更高、GC 压力更小。
实操建议：
- 初始化时用
time.NewTicker(500 * time.Millisecond)，避免在循环中反复创建 - 务必在退出前调用
ticker.Stop()，否则 goroutine 和 timer 会泄漏 - 用
select+ticker.C等待，不要直接读取通道（防止阻塞） - 若需动态调整间隔（如退避重试），不能复用
ticker，应Stop()后新建
HTTP 请求必须带超时控制，且超时值要小于轮询间隔
短轮询本质是高频发请求，一旦后端响应慢或网络卡顿，没设超时的 http.Client 会一直挂起 goroutine，很快耗尽连接池甚至内存。更危险的是：如果超时设成 2s，但轮询间隔只有 800ms，多个请求会堆积，形成“请求雪崩”。
实操建议：
- 用自定义
http.Client，设置Timeout（总超时）和Transport的IdleConnTimeout、MaxIdleConnsPerHost -
Timeout应 ≤ 轮询间隔 × 0.7，例如间隔 1s，则设Timeout: 700 * time.Millisecond - 禁用默认 client：
http.DefaultClient的超时是 0，且连接池参数保守，不适合轮询场景 - 错误处理时区分
net/url.Error（网络层）和context.DeadlineExceeded（超时），前者可立即重试，后者说明服务端已来不及响应，应考虑降频
用 context.WithTimeout 包裹单次请求，别依赖 client 超时兜底
仅靠 http.Client.Timeout 无法覆盖所有阻塞点——比如 DNS 解析卡住、TLS 握手僵死、或中间代理无响应。这些阶段发生在 client 超时计时开始前，Client.Timeout 完全无效。必须用 context 主动控制整个请求生命周期。
实操建议：
- 每次发起请求前，调用
ctx, cancel := context.WithTimeout(parentCtx, 600*time.Millisecond) - 把
ctx传给http.NewRequestWithContext(ctx, ...)，确保 DNS、连接、TLS、读响应全部受控 - 立刻 defer
cancel()，避免 context 泄漏（即使请求成功也要 cancel） - 不要把 long-lived context（如
context.Background()）直接传入轮询循环，否则一次 cancel 会杀死全部后续请求
轮询状态需原子更新，避免竞态导致重复处理或丢失事件
短轮询常用于监听服务端状态变更（如任务完成、消息到达）。若响应解析后更新本地状态用普通变量（如 lastSeenID int），多 goroutine 并发读写必然竞态——可能两次响应都读到旧值，都触发相同逻辑；也可能新值被旧值覆盖，导致事件丢失。
实操建议：
- 用
sync/atomic操作整型状态（如atomic.StoreInt64(&lastID, id)、atomic.LoadInt64(&lastID)） - 若状态是结构体或需条件更新，用
sync.Mutex或sync.RWMutex，锁粒度尽量小（只包状态字段，不包 HTTP 调用） - 避免在锁内做网络 I/O 或长时间计算，否则阻塞其他轮询周期
- 关键判断逻辑（如 “收到新消息才触发回调”）必须放在锁保护下完成，不能先读再判断再写
短轮询的性能瓶颈从来不在“怎么发请求”，而在“如何让每次请求的结果可靠落地”。超时控制、定时器选型、状态同步这三处，任意一个松懈，都会让看似稳定的轮询在压测或异常网络下迅速退化为资源黑洞。
