std::merge不支持多路合并，正确方案是用priority_queue实现多路归并或两两递归合并；deque迭代器不可转指针，应避免取地址或强制转换。
std::merge 不能直接用于多个 deque
标准库没有提供 std::merge 的多路重载版本，传入三个及以上迭代器范围会编译失败。试图把多个 std::deque 先拼接再调用 std::inplace_merge 是错的——std::inplace_merge 要求所有数据在**同一个容器内**且有明确分界点，强行 a.insert(a.end(), b.begin(), b.end()) 会导致 O(N) 拷贝+可能的内存重分配，后续归并反而更慢、更不可控。
常见错误现象包括：程序崩溃（越界写）、结果乱序、部分元素丢失（比如漏掉某个 deque 的尾部）。根本原因是误把“合并多个独立有序序列”当成“合并单容器内两段有序子序列”来处理。
多路归并必须用 std::priority_queue + 迭代器封装
这是唯一能保证 O(N log k) 时间、O(k) 空间、且不破坏原始 deque 的通用方案。核心是把每个 deque 的当前首元素作为候选，用最小堆动态选出最小值，弹出后推进对应 deque 的迭代器。
关键操作步骤：
立即学习“C++免费学习笔记（深入）”；
- 定义结构体（或
std::tuple），包含：std::deque<t>::iterator</t>、当前值、所属 deque 索引 - 初始化堆时，对每个非空 deque 取
front()构造节点并 push；注意不能用begin()直接解引用——若 deque 为空会 UB - 每次 pop 后，对该 deque 执行
pop_front()，再检查是否仍非空；若非空，取新front()推入堆 - 输出目标建议用
std::vector或预分配的std::deque，避免频繁扩容
容易踩的坑：忘记检查 deque 是否为空就调 pop_front()；把迭代器存成值而非引用/指针导致推进失效；比较逻辑没包装好导致堆顶选错。
两两递归合并（pairwise merging）适合小 k 场景
当 deque 数量 k ≤ 8 且各 deque 长度较均衡时，用 std::merge 两两合并更稳。它复用标准库实现，规避了手动管理迭代器的风险，总时间复杂度仍是 O(N)，常数略高但可接受。
实操要点：
- 输入用
std::vector<:deque>></:deque>存储，别用裸指针数组——后者无法移动语义，易内存泄漏 - 每次合并前必须
result_deque.resize(a.size() + b.size())，传result_deque.begin()作输出迭代器；只声明std::deque<t> result</t>就 merge 会写到begin() == end()区域，直接 UB - 合并完立即
std::move到下一层，避免无谓拷贝 - 若某轮只剩一个 deque，直接移入下一层，别试图 merge 它自己
性能提示：k=2 时和直接调 std::merge 几乎无差别；k≥16 时多路归并优势明显，pairwise 会多做 log₂k 层合并。
deque 迭代器不能直接转成指针
std::deque::iterator 不是原生指针，不能用 &*it 安全取地址——deque 内部是分段存储，*it 返回的是临时对象引用，取地址行为未定义。调试时看到地址连续只是巧合，上线后可能因内存布局变化而崩溃。
如果真需要指针语义（例如传给 C 接口），只能走迂回路线：
- 把目标 deque 元素 copy 到
std::vector<t></t>，再用&vec[0] - 或用
std::span<const t>(it, std::next(it, n))</const>（C++20），但 span 本身也不提供指针转换 - 绝不要 cast 迭代器为
T*，不同 STL 实现底层结构差异大，glibcxx 和 libc++ 行为不一致
真正需要“指针变换”的场景极少，多数时候是误以为必须传指针——其实用迭代器范围（first/last）更安全、更符合 STL 习惯。
