go 的 select 语句本身不会丢弃已就绪的通道事件；当通道发送（如 timer.c）发生时，若无 goroutine 立即接收，该发送将阻塞等待，直到下一次 select 准备就绪并成功接收——数据不会被忽略或丢失。
go 的 select 语句本身不会丢弃已就绪的通道事件；当通道发送（如 timer.c）发生时，若无 goroutine 立即接收，该发送将阻塞等待，直到下一次 select 准备就绪并成功接收——数据不会被忽略或丢失。
在 Go 并发模型中，select 是用于多路通道通信的控制结构，但它不负责缓冲或缓存“未及时捕获”的通道事件。关键在于：通道行为决定是否丢失，而非 select 本身。
以你提供的代码为例：
for {
select {
case <-timer.C:
// block A: 处理定时器触发
default:
// block B: 耗时约 2 秒的同步操作
}
}假设 timer 是一个 time.Timer（例如 time.NewTimer(500 * time.Millisecond)），它会在到期时向只读通道 timer.C 发送当前时间。此时：
- ✅ timer.C 是一个无缓冲通道（这是 time.Timer.C 的默认行为）；
- ✅ 当 timer 到期，Go 运行时会尝试向 timer.C 发送时间值；
- ❌ 若此时 select 正卡在 default 分支执行耗时的 block B（2 秒），则 select 未处于监听状态，timer.C 的发送操作将阻塞，直到下一轮循环进入 select 并准备好接收；
- ✅ 因此，case <-timer.C 在下一次迭代中立即就绪并被执行（无需重新触发定时器），block A 将如期运行。
? 补充说明：time.Timer 的底层实现确保了“到期即发送”，且该发送是同步阻塞的——它不会因无人监听而丢弃信号，也不会自动重发。这正是 Go 通道作为同步原语的设计哲学：发送者与接收者必须协调，但协调时机由通道自身保证，而非依赖 select 的轮询频率。
⚠️ 注意事项：
- 若使用 time.After() 或 time.Tick()，其返回的通道同样是无缓冲的，行为一致；
- 若误用有缓冲通道（如 ch := make(chan time.Time, 1)）并手动写入，且缓冲区已满，则后续发送会立即阻塞或 panic（若非 goroutine 安全），但这属于通道配置问题，与 select 无关；
- default 分支的存在使 select 变为非阻塞轮询，但它仅影响当前轮次的“是否等待”逻辑，绝不影响已发生的通道发送事件的命运。
✅ 正确实践建议：
- 对于需严格响应定时事件的场景（如心跳、超时检查），避免在 default 中执行长耗时同步操作；可将其移至 goroutine 或拆分为异步任务；
- 如需容忍一定延迟但保障不丢事件，当前模式是安全的；
- 若需精确调度（例如每 500ms 必须执行一次，无论前次是否完成），应考虑 time.Ticker 配合带缓冲的通道 + 显式消费逻辑，或使用 time.AfterFunc 等替代方案。
总之，Go 的通道 + select 组合提供了可预测的同步语义：没有“错过”的事件，只有“等待被接收”的事件。理解这一点，是写出健壮并发程序的关键基础。
