priority_queue默认按大根堆排序，高优先级值反而后执行；需自定义比较器：紧急程度与数值成反比时用std::greater或a.priority>b.priority，成正比时重载operator
priority_queue 默认比较器不支持自定义优先级逻辑
直接用 std::priority_queue 存任务对象时，它默认按 operator 降序排列（即最大堆），但多数调度场景需要「数值越小优先级越高」（如优先级数字 1 > 2 > 3），这时默认行为是反的。<br>常见错误是没重载比较逻辑，结果高数字任务反而先执行。
正确做法是提供自定义比较器，让 priority_queue 按需升序或降序：
• 若用 int priority 字段，且值越小越紧急，应使用 std::greater 或 lambda 返回 a.priority > b.priority
• 若用结构体，必须定义 operator 或传入仿函数
struct Task {
int priority;
std::function<void()> fn;
bool operator<(const Task& rhs) const {
return priority > rhs.priority; // 注意：这里反向比较，实现最小堆
}
};
std::priority_queue<Task> queue; // 此时 priority 小的在队首
任务对象必须可移动或支持深拷贝
往 priority_queue 里 push std::function 或带指针/资源的对象时，若类型不可拷贝也不可移动（比如含 std::unique_ptr 未显式 move），编译会报错：use of deleted function。
实操建议：
• 所有任务类成员尽量用值语义（如 std::string、int）
• 若必须持有独占资源，确保类已定义移动构造函数和移动赋值运算符
• push 时显式用 std::move(task) 避免冗余拷贝
• 不要存裸指针——生命周期无法保证，调度时可能访问已释放内存
立即学习“C++免费学习笔记（深入）”；
多线程环境下 priority_queue 不是线程安全的
std::priority_queue 本身无内部锁，多个线程同时 push 或 top/pop 必然导致数据竞争，表现可能是崩溃、乱序、甚至静默逻辑错误。
常见误用：
• 用全局 priority_queue + 多个工作线程直接操作
• 只对 pop 加锁，但没锁住 top 和 pop 的原子性（竞态窗口）
安全做法：
• 用 std::mutex 包裹整个 push/top/pop 序列
• 更高效的选择是改用无锁队列（如 moodycamel::ConcurrentPriorityQueue），但需引入第三方
• 或者采用「单生产者-单消费者」模型，用条件变量 + 队列分离调度与执行
调度器需要处理任务延迟与时间轮盘扩展性问题
纯 priority_queue 只适合立即执行或按静态优先级排序的任务。一旦加入「5 秒后执行」「每 10 秒重复」这类时间维度需求，它就力不从心了——因为每次插入都要 O(log n)，且无法高效剔除过期任务。
这时候别硬改 priority_queue，考虑分层：
• 近期任务（如 1 秒内）走 priority_queue（低延迟）
• 中远期任务走基于时间轮（timing wheel）的结构，例如用 std::vector<:list>></:list> 分桶
• 所有任务统一用绝对时间戳做主排序键，避免浮点误差累积
真正容易被忽略的是：优先级和延迟不是正交的。一个「高优先级但 10 秒后才执行」的任务，不该抢占「低优先级但现在就能跑」的任务——这需要复合排序键，比如 std::tuple<time_point priority seq_id></time_point>。
