Python heapq.merge：几路数据混在一起，为什么结果仍然乱序
把几个服务导出的时间记录合成一份报表时，看到 heapq.merge 会返回有序流，很容易直接把几路原始列表交给它。结果前面几项升序，后面却突然出现更小的值。问题并不是归并偶尔失灵，而是其中一路原本没有按同一规则排好。归并需要的前提，不能由函数名称替你补齐。
先复现一条内部乱序的输入
下面例子全在内存运行，用整数模拟时间序号。保存为 demo.py 后运行 python demo.py。第一路的三比一先出现，第二路是正常升序；随后分别展示输入修正、降序归并和按字典字段归并。末尾断言不仅检查正确例子，也明确证明第一份输出确实没有全局有序。
from heapq import merge
left, right = [3, 1], [2, 4]
bad = list(merge(left, right))
good = list(merge(sorted(left), sorted(right)))
descending = list(merge([4, 2], [3, 1], reverse=True))
print("unsorted:", bad)
print("sorted:", good)
print("descending:", descending)
streams = [
[{"time": 1, "name": "z"}, {"time": 3, "name": "a"}],
[{"time": 2, "name": "b"}],
]
records = list(merge(*streams, key=lambda row: row["time"]))
print("times:", [row["time"] for row in records])
assert bad != sorted(left + right)
assert good == [1, 2, 3, 4]
assert descending == [4, 3, 2, 1]
assert [row["time"] for row in records] == [1, 2, 3]第一行的结果是二、三、一、四，看到一之前，程序已经输出了前面的数。第二行把两路分别排好才交给 merge，得到一到四。这个例子说明 merge 不会预先遍历每一路，为它重新整理内部顺序；它在各路目前可见的开头之间选择下一项，所以藏在后面的更小值来不及参与前面的比较。
键和方向必须在所有输入上统一
reverse=True 也不是“把升序输入倒着读”。它要求每一路本身已经从大到小排列。代码先准备降序输入，才得到四、三、二、一。如果某一路升序、另一路降序，设置参数并不能修复这种混合。排序的方向应是数据契约的一部分，在生产这些列表的步骤就保持一致。
AI生成概念示意图：两路输入先各自保持顺序，合流之后才能得到连续有序的结果。
字典记录则展示了 key 的另一半约定：输入必须已经按相同的时间字段排序，而不是按名称排好后再临时换一个比较键。第四行输出一、二、三，验证的是时间键的顺序。如果相同时间下还需要明确的次序，例如按来源编号排列，就应把它加入组合键，并让每一路也按这份组合键排序。
惰性输出的收益与边界
merge 返回迭代器，消费多少才逐步推进多少，适合归并已经有序的大量输入。例子为了打印和断言，特意把结果转成 list，这会收集完整输出，不该照搬到很大的任务里后又宣称节省了全部内存。真正逐项处理时，仍要考虑各路输入的读取成本，以及下游是否又把结果全部缓存起来。
如果数据本来没有排序，最直白的方案可能就是把有限数据汇总后统一排序。另一种方案是分别排序后归并，但前面的排序仍然需要时间和存储。选择取决于数据是否已经分批有序、是否可流式读取，而不是哪个函数名字看起来更专业。不要省略排序步骤后，把更低的开销当成等价优化。
归并通常也不会主动验证每一路有序。需要诊断上游质量时，可以在测试或可接受开销的入口中记录相邻键并检查是否倒退。一旦发现异常，应保留来源与位置，再决定中止或走备用排序流程。已经输出的记录不能仅靠后面发现错误就自动撤回，因此必须明确下游何时把结果当成最终结果。
本例只验证确定性的整数及字典时间键，不讨论缺失值、不可比较类型或无限输入的业务策略。实际接入前，先统一字段类型、相同键的次序和升降方向，再用一路乱序的负例检验告警能否触发。把前提写出来，归并才是一项可依赖的处理步骤。
资料核对日期：2026年10月2日（北京时间）。示例在 Python 3.12.14 中独立运行，具体输出以本文实测为准。
官方参考：Python heapq.merge 官方文档。
