双指针合并两个有序列表可实现O(m+n)时间复杂度，优于拼接后排序的O((m+n)log(m+n))；需初始化i,j=0，比较后推进下标，一方耗尽则直接extend剩余部分，注意空列表和有序性前提。
用双指针合并两个有序列表，别直接拼接再排序
直接 sorted(a + b) 看似简单，但破坏了“有序”前提，时间复杂度退化到 O((m+n) log(m+n))，而双指针能压到 O(m+n)。关键不是“能不能做”，而是“为什么必须用双指针”——因为归并排序的合并步就是靠它维持稳定性和线性耗时。
实操建议：
- 初始化两个下标
i = 0,j = 0，逐个比较a[i]和b[j]，小的进结果，对应下标加一 - 一个列表走完后，把另一个剩余部分直接 extend 进去，别再循环比较
- 注意边界：空列表要提前判断，否则
a[i]会触发IndexError - 如果原列表是升序，结果也是升序；若一个是降序，得先反转或改比较逻辑，不能硬套
合并三个及以上有序列表，用 heapq.merge 更稳
heapq.merge 是 Python 内置的多路归并实现，底层用最小堆维护各列表当前最小元素，比手写多指针更可靠，尤其当列表数量动态变化或长度差异极大时。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 手动写三指针、四指针，逻辑爆炸，
if/elif/else嵌套失控，漏掉某路没推进下标 - 误以为
heapq.merge返回 list —— 它返回的是迭代器，要转成 list 得显式调用list() - 传入非有序序列，结果错乱，
heapq.merge不校验有序性，只负责归并
示例：list(heapq.merge([1,4,5], [2,3,6], [0,7])) → [0, 1, 2, 3, 4, 5, 6, 7]
自定义比较逻辑（比如按字符串长度合并），别改原始数据
归并过程依赖“可比较性”，如果列表元素类型不支持直接比较（如字典、自定义对象），或你想按特定字段合并（比如按 item['score'] 升序），不能靠改数据结构来“凑合”，得在比较环节介入。
实操建议：
- 用
key函数预处理：先统一映射为可比值，比如[{'name': 'a', 'score': 85}, ...]→ 提取[85, 92, ...]，但注意这会丢失原始结构，慎用 - 更安全的做法是封装成元组：
(item['score'], item)，这样既能排序又能保留原对象 - 如果必须用双指针，比较时写成
a[i]['score'] ，别试图给类加 <code>__lt__——除非你控制全部输入源 - 注意 None 值：如果 score 可能为
None，直接比较会报TypeError，得提前转成 float('-inf') 或用or 0类似兜底
性能敏感场景：避免反复创建新列表，考虑 in-place 合并或生成器
如果列表很大（比如百万级），每次 append 都可能触发内存扩容；如果只是遍历结果，根本不需要一次性全加载进内存。
实操建议：
- 用生成器替代 list 构建：把双指针逻辑包进
def merge_iter(a, b):，用yield逐个产出，调用方用 for 消费即可 - in-place 合并仅适用于其中一个列表有足够尾部空间（如
a预留了 len(b) 空位），此时从后往前填，避免覆盖未读数据 -
heapq.merge默认就是惰性求值，适合流式处理，但要注意：一旦转成list()就全加载了 - 测试时别只看小数据，用
timeit跑万级数据对比，sorted(a+b)在 10 万量级上就明显慢于双指针
真正容易被忽略的，是“有序”这个前提本身——它不在代码里，而在你的数据源头和业务约束中。一旦某路数据悄悄无序了，所有归并逻辑都会静默出错，且很难定位。
