任务优先级排序需与业务语义对齐，优先级字段须final且构造时确定；比较器应稳定、无副作用，采用多维权衡策略；线程池须显式使用优先级队列初始化；动态调权需取消重投而非原地修改。
核心在于让任务排序逻辑与业务语义对齐，而不是简单按数字大小排。优先级比较器不是“加个字段就完事”，它得稳定、可预测、能应对真实场景变化。
任务类必须设计为不可变且可比较
任务一旦入队，其用于排序的字段就不能再变——否则堆结构会损坏，导致调度错乱甚至崩溃。常见错误是把 System.nanoTime() 或实时计算值塞进 compareTo。
- 优先级字段应声明为
final int priority，构造时确定，后续只读 - 若需引入时间衰减（防低优任务饿死），用入队时冻结的“初始时间戳”参与计算，例如：
(priority * 1000L) - (queueTimeNs - System.nanoTime())，其中queueTimeNs是任务创建时记录的纳秒时间 - 避免在
compareTo中调用任何可能抛异常、阻塞或依赖外部状态的方法（如数据库查询、HTTP 请求）
比较器要表达真实的调度意图
“数值小=优先高”是常见约定，但实际业务中往往需要多维权衡。比如语音识别服务里，实时流任务既要优先级高，又要按到达顺序保序；而批量转写任务可以降级但不能无限延迟。
- 推荐用组合策略：先比紧急程度（如
deadline），再比静态优先级（如level），最后比入队时间（防饥饿） - 示例比较逻辑（Java）：
(Long.compare(a.deadline, b.deadline) != 0) ?<br> Long.compare(a.deadline, b.deadline) :<br> (Integer.compare(b.level, a.level) != 0) ?<br> Integer.compare(b.level, a.level) :<br> Long.compare(a.enqueueTime, b.enqueueTime)
- C++ 中若用
std::priority_queue，对应比较器应返回true当a应排在b之后（即a优先级更低），所以常写成lhs.priority > rhs.priority
线程池必须用支持优先级的队列初始化
不是所有线程池都支持插队。Java 的 ThreadPoolExecutor 默认队列是无序的 LinkedBlockingQueue，必须显式传入 PriorityBlockingQueue 才生效。
- 不能用
Executors.newFixedThreadPool(4)然后试图替换队列——会抛UnsupportedOperationException - 正确方式：
new ThreadPoolExecutor(core, max, 60, TimeUnit.SECONDS,<br> new PriorityBlockingQueue<>(11, yourComparator))
- C++ 中同理，不能用
std::queue包裹std::function，必须封装Task结构体并重载operator 或传自定义 <code>Compare
动态调整优先级需“取消+重投”，而非原地修改
无论是 Java 的 PriorityBlockingQueue 还是 C++ 的 std::priority_queue，都不支持更新已入队元素的优先级字段并自动重堆。强行修改只会让队列内部结构失效。
- 当任务因超时、用户干预或业务规则需要升权时，应调用
cancel(true)（Java）或标记为已取消（C++），再构造一个新任务以更高优先级重新提交 - 可配合唯一 ID + 状态映射表实现去重，避免同一任务被重复执行
- 若频繁升降权，考虑改用支持任意节点删除的容器，如 Java 的
TreeSet（需自行加锁）或 C++ 的std::set
