因为std::thread和std::async不管理任务队列与调度逻辑，仅封装os线程或延迟执行，无法控制任务排队顺序；优先级必须由应用层多级队列+条件变量实现，按high/normal/low顺序轮询取任务，避免依赖不可控的os调度。
为什么标准 std::thread 和 std::async 无法直接支持优先级任务
因为 C++ 标准库的线程抽象完全不暴露调度策略——std::thread 启动后即交由 OS 调度器管理，而 std::async 的执行策略（std::launch::async 或 std::launch::deferred）也不控制线程内任务的排队顺序。你无法靠改写 std::packaged_task 或封装 std::function 就让高优先级任务“插队”，除非自己管队列。
用多级队列 + 条件变量实现优先级调度
核心思路是：不依赖 OS 线程优先级（那属于进程级、难控且跨平台行为不一致），而是在线程池内部维护多个就绪队列（比如 high_queue、normal_queue、low_queue），worker 线程每次唤醒时按固定顺序轮询：先查高优队列，空了再查中优，最后低优。这样能保证语义上的优先级，且不引入系统级依赖。
- 每个队列用
std::queue<:function>> </:function>，配合std::mutex和std::condition_variable保护 - 提交任务时根据优先级参数 push 到对应队列，并 notify_one（注意：notify_all 不必要，且有性能损耗）
- worker 循环中用
wait_for配合超时避免饿死低优任务（例如 10ms 内没高优任务就降级检查） - 避免锁粒度太粗：不要用一个大锁包住所有队列；应为每个队列配独立
std::mutex，否则高优入队会阻塞低优出队
std::priority_queue 不适合直接当任务队列用
看起来很自然，但实际踩坑多：它底层是堆，不支持随机删除或遍历；一旦某个任务需要取消（比如超时），你就没法从中间移除它——只能标记为已取消并在执行前跳过，这导致积压无效任务。更严重的是，std::priority_queue 的比较函数必须严格弱序，而任务对象通常没有天然可比字段；若用时间戳或 ID 排序，又容易因并发插入导致顺序错乱（缺乏插入原子性）。
所以推荐用分层队列，而不是单个带比较的优先队列。
Windows/Linux 下设置真实线程优先级要谨慎
如果你真想影响 OS 调度器（比如让高优 worker 线程获得更高 CPU 时间片），可以用：
• Linux：pthread_setschedparam + SCHED_FIFO/SCHED_RR（需 root）
• Windows：SetThreadPriority（如 THREAD_PRIORITY_HIGHEST）
但这不是替代队列优先级的方案，而是叠加手段。而且风险明显：
- 非 root 用户在 Linux 上设实时调度策略会失败，返回
EACCES - 多个高优线程争抢 CPU 可能导致低优线程彻底饿死（尤其在单核环境）
- C++20 的
std::jthread也不提供接口封装这些，仍得手动native_handle()转换
真正稳定的做法，是把优先级逻辑收在应用层队列里，OS 层保持默认调度策略——这样移植性强，也更容易测试和压测。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
