用多个带缓冲channel（如highPrioCh、lowPrioCh）配合单goroutine消费者轮询实现优先级队列，按优先级顺序非阻塞读取，辅以配额或超时机制防饥饿；禁用select随机选、heap单channel等错误方案，并通过chan方向限定和context管控生命周期防goroutine泄漏。
用 channel 实现带优先级的任务队列，别直接塞 goroutine
Go 里没有内置优先级调度器，goroutine 本身无优先级概念。想让高优任务先执行，必须自己建队列 + 控制消费顺序。常见错误是每个任务都起一个 goroutine 并发跑，结果优先级完全失效——因为调度权在 runtime，你无法干预谁先被 M 绑定、谁先抢到 G。
正确做法是：用多个带缓冲的 channel（比如 highPrioCh、lowPrioCh），再启一个**单 goroutine 消费者**，按优先级轮询读取。这样逻辑可控，且避免竞态。
- 不要用
select随机选 channel —— 它是公平的，不保证高优先读 - 用
select+default非阻塞尝试读取，按优先级顺序显式检查 - 任务结构体需包含
priority字段（如int，值越小优先级越高） - 若使用
sync.Pool复用任务对象，注意priority必须重置，否则残留值导致误调度
select 轮询时如何避免饥饿？
如果只按顺序 select 高优 channel → 中优 → 低优，低优任务可能永远等不到机会。尤其当高优任务持续涌入时，低优 channel 一直有数据，select 每次都命中它。
解决方法是引入「配额」或「时间片」机制，例如每处理 3 个高优任务，强制读一次中优；或用 time.After 加超时兜底：
立即学习“go语言免费学习笔记（深入）”；
for {
select {
case task := <-highPrioCh:
handle(task)
highCount++
if highCount%3 == 0 {
goto tryMedium
}
default:
// 防止 busy-loop，但不阻塞
time.Sleep(1 * time.Microsecond)
continue
}
tryMedium:
select {
case task := <-mediumPrioCh:
handle(task)
default:
// 跳过，继续下一轮
}
}
更稳妥的是用 time.Tick 控制最大等待时长，避免某个 channel 长期独占。
为什么不用 heap 包 + 单 channel？
有人会想：把任务全塞进一个 channel，后台用 container/heap 维护最小堆，每次 取出 top。这看似简洁，但实际不可行：
-
channel是 FIFO，无法按优先级出队；你不能“从 channel 中挑一个最高优的取”，只能按写入顺序收 - 若改用无缓冲 channel + 手动管理 heap，就得加锁保护 heap，失去 Go 的 channel 通信优势
- heap 插入/删除是
O(log n)，而多 channel 轮询是O(1)per check，吞吐更稳 - 调试困难：任务卡在 heap 里还是 channel 里？trace 不直观
所以，多 channel 分流仍是生产环境最易理解、最易监控的选择。
goroutine 泄漏风险在哪？
最容易被忽略的是：消费者 goroutine 退出后，生产者还在往 channel 发任务，造成 goroutine 永久阻塞（尤其是无缓冲 channel）。
必须做两件事：
- 所有
channel声明为chan 或，限制方向，避免误写 - 用
context.Context控制生命周期，消费者监听ctx.Done()，收到信号后 drain channel 并 close - 生产者端用
select+ctx.Done()判断是否还能发，而不是盲目ch
没做这些，服务 reload 或配置变更时，几十个 goroutine 就卡死在 send 上，内存缓慢上涨。
