不能只用 time.tick 因其返回的 channel 不可关闭且底层使用全局定时器，长期运行会导致 goroutine 和 timer 泄漏；应使用 time.newticker 配合 ctx.done() 实现可取消、可退出的心跳机制。
Go channel 心跳检测为什么不能只用 time.Tick
因为 time.Tick 返回的 channel 没法被关闭，且底层是全局定时器，长期运行会泄漏 goroutine 和 timer 资源。心跳检测需要可控制启停、可响应退出信号，必须自己构造可取消的 ticker。
- 用
time.NewTicker替代time.Tick，方便后续调用ticker.Stop() - 心跳 goroutine 必须监听
ctx.Done()，否则程序退出时 goroutine 无法回收 - 别把心跳发送逻辑直接塞进
select的default分支——这会导致“伪心跳”，实际没发出去
如何用 channel 实现带超时响应的心跳保活
核心不是“发心跳”，而是“确认对方还活着”。所以发送端要配接收端，接收端得在规定时间内回一个 ACK，否则触发重连或断开。
- 心跳发送侧：用
ticker.C触发，向连接写入ping帧（如"PING\n"），同时启动一个time.AfterFunc或单独 goroutine 等待 ACK - 心跳接收侧：读到
"PING"就立刻回"PONG\n"，不排队、不缓冲 - ACK 超时判断必须独立于发送周期：比如心跳间隔 10s，但等待 ACK 最多等 3s，超时即判定失联
示例关键片段：
select {
case <-ticker.C:
conn.Write([]byte("PING\n"))
// 启动 ACK 等待
ackTimer := time.NewTimer(3 * time.Second)
defer ackTimer.Stop()
select {
case <-ackChan: // 收到 PONG
case <-ackTimer.C:
log.Println("no ACK, disconnecting")
return
}
case <-ctx.Done():
return
}channel 关闭时机错位导致 panic 的典型场景
最常见的是：心跳 goroutine 还在往已关闭的 conn 写数据，或者往已关闭的 ackChan 发送 "PONG"，触发 send on closed channel panic。
立即学习“go语言免费学习笔记（深入）”；
- 所有写 channel 的地方，都要先检查是否已关闭——但更稳妥的做法是用
select+default配合ok判断 - 不要在多个 goroutine 里并发关闭同一个 channel；统一由 owner（如连接管理器）负责关闭
- 心跳 goroutine 退出前，必须确保
ticker.Stop()已调用，否则ticker.C仍会持续发送，可能撞上已关闭的 channel
为什么用 chan struct{} 而不是 chan bool 做信号通道
语义清晰、内存占用最小、且能明确表达“只传通知，不传数据”的意图。用 bool 容易让人误以为要读取具体值（比如 true/false 表示不同状态），反而增加理解负担。
- 发送信号：直接
sigChan ，无歧义 - 接收信号：用
即可，不需要 <code>ok判断（除非你关心 channel 是否已关） - 如果后续要扩展为带 payload 的信号（比如错误码），那就该换
chan error或自定义 struct，而不是硬塞bool
心跳机制真正难的不是发 ping，是界定“什么时候算死”——网络延迟、GC STW、IO 阻塞都可能让单次 ACK 延迟，但连续两次超时才该断连。这个阈值和超时时间的组合，得结合你的协议栈和部署环境反复调。
