Go原生不支持带权重的goroutine调度，必须自建“权控分发器”：用container/heap实现最大堆管理任务，由单个dispatcher协程按权重出队并推入无缓冲channel，worker从该channel取任务执行；全程需sync.Mutex加锁，同权任务须用ID等第二键保序，且worker中须recover防panic卡死。
Go 语言原生不支持基于权重的 goroutine 调度，go 关键字启动的 goroutine 没有优先级、没有排队顺序、也不感知权重——它只是把任务扔进运行队列，由 runtime 的 G-P-M 调度器按 FIFO（或带 work-stealing 的近似公平）分发。真要按权重跑任务，必须绕过 go 直接调度，自己建一层“权控分发器”。
为什么直接用 go + 权重字段完全无效
常见错误是给任务结构体加个 Weight int 字段，然后写 if task.Weight > 5 { go task.Run() }。这只会导致：高权任务早启动、低权任务晚启动，但一旦并发起来，所有 goroutine 就进入 runtime 统一调度池，权重信息彻底丢失。
-
chan是 FIFO，哪怕你用make(chan Task, 100)，消费顺序只取决于发送顺序，和Task.Weight无关 - 多个 worker 从同一个
chan取任务时，谁抢到谁执行，runtime 不看权重 - 无缓冲
chan会让高权任务卡在发送端，反而比低权任务更慢进队 -
context.WithTimeout或runtime.Gosched()都不能改变 goroutine 在就绪队列里的位置
用 container/heap 实现带权任务队列
核心是把任务先存进堆，再由单个 dispatcher 协程按序取出、推给 worker。堆必须实现 heap.Interface，且 Less(i, j int) bool 必须定义在切片类型上（不是 Task），否则 heap.Push 不生效。
- 用最大堆（
Weight大的排前面）：在Less里写tasks[i].Weight > tasks[j].Weight - 同权任务需第二排序键（如
ID或CreatedAt），否则出队顺序不确定 - 别用
sort.Slice替代heap：插入/删除是O(n)，而heap.Push/heap.Pop是O(log n) - 权重更新不能原地改字段后忽略堆性质；必须
heap.Remove+heap.Push，且全程加sync.Mutex
dispatcher + worker 协程如何安全衔接
worker 不能直接操作堆——会竞态。必须让 dispatcher 独占堆，只负责取任务、发到 dispatchCh chan Task，worker 从该 channel 收。
立即学习“go语言免费学习笔记（深入）”；
-
dispatchCh建议用无缓冲或小缓冲（如1），避免高权任务在 channel 里被低权任务“插队”滞留 - 堆的所有读写（包括
heap.Len()）都必须加锁，哪怕只读——heap.Pop会修改底层数组长度 - worker 执行
task.Fn()前必须defer recover()，否则 panic 会导致该 worker 退出，后续任务卡死 - 别在
task.Fn里调runtime.Goexit()或长时间阻塞（如time.Sleep(10 * time.Second)），这等于永久占用 worker
权重值设计不当的典型后果
权重不是越大越好，数值设计直接影响调度行为和稳定性：
- 用
time.Now().UnixNano()当权重？数值过大易溢出，且每次提交都不同，失去可复现性 - 硬编码
1/10/100？扩展性差，调试时无法快速定位是权重逻辑还是执行逻辑出错 - 权重为
0或负数？堆比较可能 panic，或导致任务永远排在末尾（饥饿） - 动态调权（如超时升权）必须加锁保护堆操作，且要考虑 dispatcher 是否正在 Pop 中途——建议用 CAS 或 double-check
最易被忽略的一点：dispatcher 和 worker 的数量配比。如果 dispatcher 太慢（比如加了日志、校验、网络调用），它就成了瓶颈；如果 worker 太少，高权任务取出来也得排队等执行——权重只管“谁先取”，不管“谁先完”。
