必须用std::priority_queue配合std::chrono::steady_clock和细粒度锁，否则高优任务被低优卡住、延迟不可控、取消无法落地；裸用会因非线程安全、单字段排序、system_clock跳变、全队列锁、轮询精度差等问题崩溃。
必须用 std::priority_queue 配合 std::chrono::steady_clock 和细粒度锁起步，否则高优任务会被低优卡住、延迟不可控、取消无法落地——这不是优化选项，是功能底线。
为什么裸用 std::priority_queue 会崩
它本身不线程安全，但问题远不止加把锁那么简单：
operator 只比priority字段？同时间任务顺序失控，紧急任务可能被低优“插队”- 用
std::system_clock做基准？NTP 调整会让定时器跳变甚至倒退，fire_time判断直接失效 - 锁整个队列？所有
push/top/pop串行化，吞吐随并发线程数陡降 - 靠
std::this_thread::sleep_for轮询？Linux 下实际唤醒偏差常超 10ms，毫秒级调度成空谈
正确比较逻辑必须是双键排序：fire_time 早者优先；时间相同时，priority 数值小者（如 0=紧急）优先：
struct Task {
std::chrono::steady_clock::time_point fire_time;
int priority = 0;
std::function<void> action;
bool operator rhs.fire_time;
return priority > rhs.priority;
}
};</void>
std::condition_variable::wait_until 怎么用才不掉精度
关键不是“等多久”，而是“等哪个时间点”以及“醒来后怎么验”：
- 每次循环只取
task_queue.top()，检查fire_time ；未到期就调cv.wait_until(lock, task_queue.top().fire_time) - 唤醒后必须重新加锁，并再次判断
task_queue.top().fire_time ——防止虚假唤醒 - 执行
action()前必须unlock()，否则回调阻塞会导致新任务无法插入、调度线程卡死 - 插入任务后只调
cv.notify_one()，别用notify_all()，避免惊群和无谓竞争
多级队列轮询比单堆更能抗饥饿，但锁不能乱加
单 std::priority_queue 在持续高优任务涌入时，低优任务可能永远得不到执行。拆成独立队列是解法，但陷阱在锁粒度：
- 定义
enum class Priority { EMERGENCY = 0, HIGH = 1, MEDIUM = 2, LOW = 3 }; - 用
std::array<:queue>, 4> queues;+std::array<:mutex> mutexes;，每级一把锁 - 轮询时从
current_level开始，对每级调try_lock()；失败立即跳下一级，绝不阻塞等待 - 若某级队列为空或锁失败，递增
current_level并对 4 取模；遍历一轮后重置为 0，避免某级长期空转导致后续级别被跳过
真正容易被忽略的是：所有时间计算必须基于 std::chrono::steady_clock，且每个任务入队前需校验 delay 是否已超时——超时任务应绕过队列，直接投递至执行上下文，否则调度器会陷入“永远追不上”的状态。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
