Go 的 select 语句本身不会丢弃已发送到通道的数据；当通道有值但无 goroutine 立即接收时，该值会暂存（对带缓冲通道）或阻塞发送者（对无缓冲通道），确保数据不丢失，直到被 select 下一次轮询捕获。
go 的 `select` 语句本身不会丢弃已发送到通道的数据；当通道有值但无 goroutine 立即接收时，该值会暂存（对带缓冲通道）或阻塞发送者（对无缓冲通道），确保数据不丢失，直到被 `select` 下一次轮询捕获。
在 Go 并发编程中，一个常见误解是：如果 select 当前未处于监听状态，通道中“到来”的数据就会被忽略或丢失。实际上，这不符合 Go 通道的设计哲学——通道本质是同步/通信的协调机制，而非瞬时事件总线。其行为取决于通道类型（有缓冲 vs 无缓冲）和发送/接收的时序关系。
以问题中的典型场景为例：
timer := time.NewTimer(1 * time.Second)
for {
select {
case <-timer.C:
fmt.Println("Timer fired!")
// block A
default:
fmt.Println("Executing slow task...")
time.Sleep(2 * time.Second) // block B: takes 2 seconds
}
}关键点解析如下：
- timer.C 是一个无缓冲的只读通道，由 time.Timer 内部 goroutine 在超时时执行 c
- 当 timer 在 default 分支执行 time.Sleep(2 * time.Second) 期间触发时，该发送操作 不会失败，也不会丢弃；它会阻塞在 c ，直到有接收者就绪。
- 由于 select 在下一轮循环才再次尝试接收
✅ 正确结论：数据不会丢失，而是被可靠地“保留”直至被消费。这是 Go 通道“同步语义”的核心体现：发送与接收必须配对完成，否则至少一方挂起。
⚠️ 注意事项：
- 若使用带缓冲通道（如 ch := make(chan int, 1)），且缓冲区未满，则发送不会阻塞，即使当前无接收者；但若缓冲区已满，后续发送仍会阻塞。
- default 分支的存在使 select 变为非阻塞选择，但它只影响本次轮询的接收行为，并不干预通道底层的发送逻辑。
- 不要依赖 default 来“跳过”事件——若业务要求不丢失任何定时信号，应避免长时间阻塞 default 分支，或改用带缓冲通道 + 显式 draining 逻辑。
? 最佳实践建议：
对于高可靠性定时任务（如心跳、健康检查），推荐显式重置 timer 或使用 time.AfterFunc 配合互斥控制；若需累积多个超时事件，可使用带足够容量的缓冲通道（如 make(chan time.Time, 10)），并在 select 中持续 drain 避免溢出。
总之，Go 的通道设计天然保障了通信的完整性——你无需担心“错过”已发出的消息，只需确保接收逻辑最终能覆盖所有可能的发送时机。
