default 总是优先执行，导致 time.after 无法生效；这是非阻塞探测而非超时机制。错误写法：select { case ... default: ... }。
select 里混用 default 和 time.After 会失效
default 总是优先抢跑，它不等任何东西。只要所有 channel 都没就绪，default 立刻执行，time.After 根本没机会被选中——这不是超时，是纯非阻塞探测。
- 错误写法：
select { case → <code>default永远先触发 - 正确超时必须去掉
default，只留time.After作为可读通道参与竞争 - 若既要“立刻试一次”，又要“失败后等一会儿”，得手动包一层循环：
for !trySend(ch, data) { time.Sleep(10 * time.Millisecond) }
超时 case 必须和 channel 操作同级竞争
time.After 是个普通 channel，它的作用就是提供一个“时间到了就可读”的信号。它必须和其他 case 并列，不能藏在 default 里，也不能靠顺序控制优先级。
- 超时逻辑生效的前提：没有
default，且至少一个 channel 操作处于阻塞等待状态 -
time.After的精度受调度器影响，短于 1ms 的超时可能不准，生产环境建议 ≥10ms - 重复创建
time.After会产生小对象，高频调用可复用time.Timer（注意Reset调用时机）
default 分支里别做阻塞操作
加了 default 就以为整段逻辑是非阻塞的？错。如果在 default 里调了 http.Get 或 time.Sleep，goroutine 还是会卡住。
-
default只解决 select 本身的阻塞，不保证分支内代码非阻塞 - 常见陷阱：在
default中发起网络请求、写文件、或长时间 sleep，导致轮询退化为串行等待 - 真正轻量的
default应该只做状态记录、指标打点、或runtime.Gosched()让出时间片
多个就绪 channel 的执行顺序不可控
哪怕你把高优 channel 写在第一个 case，只要它和另一个 channel 同时就绪，select 就随机挑一个——Go 不保证顺序，也不提供优先级语法。
- 想确保某个 channel 优先处理，得提前探测：
if val, ok := - 缓冲 channel 的“几乎总是优先”依赖的是写入时机控制，不是 select 写法本身
- 多个超时 channel（如
time.After和time.After）同时就绪，同样随机选择，无法预测
实际用起来最易忽略的点是：default 和 time.After 的语义冲突——前者是“此刻放弃”，后者是“等一等再看”，二者根本不在同一抽象层级。硬凑在一起，只会让逻辑变成不可调试的状态机。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
