priorityqueue 是 .net 6+ 原生最小堆，默认数值越小优先级越高，不支持更新已入队元素优先级；需最大堆时须传自定义比较器，相同优先级无序，动态改优先级需懒删除+重入队。
直接说结论：PriorityQueue<telement tpriority></telement> 是 .NET 6+ 原生最小堆，**默认数值越小优先级越高**，不支持更新已入队元素的优先级——这是绝大多数人踩坑的起点。
为什么 Dequeue 总是取出最小数字？
因为它是默认最小堆，底层用 IComparer<tpriority>.Default</tpriority> 比较，对 int 就是升序。比如你入队 ("A", 10)、("B", 3)、("C", 7)，出队顺序一定是 B → C → A。
若要“数值越大越先出”（模拟最大堆），必须显式传入比较器：
var pq = new PriorityQueue<string int>(Comparer<int>.Create((a, b) => b.CompareTo(a))); </int></string>
- 别漏掉构造函数参数，仅靠
Enqueue时传负值（如-priority）也能绕过，但语义模糊、易错 - 字符串作优先级时按 Unicode 升序排（
"Apple"比"Zebra"优先级高），不是字典序常识意义上的“字母靠前优先” - 自定义类型作
TPriority时，必须实现IComparable<t></t>或提供IComparer<t></t>，否则运行时报InvalidOperationException
如何让相同优先级的元素保持 FIFO 顺序？
PriorityQueue 不保证稳定性：两个 Enqueue("X", 5) 和 Enqueue("Y", 5)，Dequeue 可能先出 Y。这不是 bug，是堆结构的固有特性。
需稳定顺序时，把序号塞进元素本身：
var pq = new PriorityQueue();
int seq = 0;
pq.Enqueue(("task1", seq++), 5);
pq.Enqueue(("task2", seq++), 5);
- 比较器仍只看
int优先级；当优先级相等时，元组第二项seq自动参与比较（因元组实现了IComparable） - 不要用
DateTime.Now.Ticks当序号——高并发下可能重复；用原子递增整数更安全 - 如果元素类型已是类，可在类里加
InsertOrder字段，并在IComparer<telement></telement>中联合比较
想动态改某个任务的优先级，怎么办？
原生 PriorityQueue **没有 UpdatePriority 方法**，任何试图“找到并修改”的操作都是无效的——堆内部不维护索引映射，也无法定位元素。
工业级可行方案是“懒删除 + 重入队”：
- 维护一个
Dictionary<taskid int> _currentPriority</taskid>记录每个任务当前有效优先级 - 入队时用
(taskId, priority)元组作为TElement，原始优先级为TPriority - 更新优先级时，只更新字典，不碰队列
- 出队时循环
TryDequeue(out var item, out var prio)，检查_currentPriority[item.TaskId] == prio；不匹配就丢弃，继续下一轮
这个模式在 AGV 紧急避障、设备急停等工业场景中已被验证，延迟可压到 10ms 内。但要注意：无效节点积压过多会拖慢 Dequeue，建议当无效比例超 30% 时重建队列。
PriorityQueue 和 SortedSet 到底选哪个？
别被“都能排序”误导。两者设计目标完全不同：
-
PriorityQueue是纯“取最值”场景优化：只支持Enqueue/Dequeue/Peek，均摊Enqueue是 O(1)，内存占用低，无遍历能力 -
SortedSet是有序集合：支持Remove、RemoveWhere、Find范围查询，但每次插入/删除都是 O(log n)，且元组要求所有字段可比（重复优先级 + 相同T会导致插入失败） - 如果你需要“删掉所有优先级 SortedSet；如果只是“永远只取最高优先级那个”，
PriorityQueue更轻、更快、更专一
真正容易被忽略的是：PriorityQueue 的堆结构不暴露内部状态，无法调试查看“当前所有元素按优先级排成什么样”——你只能靠 Peek 看堆顶，或清空重建来窥探。这点在排查调度逻辑异常时特别被动。
