假设我们有一个未分类列表[7,10,18,2,9,45]。使用合并排序，我们将其分两半分解
[7,10,18,2,9,45]
[7,10,18] [2,9,45]
[7,10] [18] [2,9] [45]
[7] [10] [18] [2] [9] [45]
然后备份。但是，为什么我们要将其分成一半？为什么您不仅要开始获取初始的未分类列表并立即将其分解为1个元素列表的基本案例，然后再通过一次组合两个1元素列表来备份工作，例如：
[7,10,18,2,9,45]
[7] [10] [18] [2] [9] [45]
为什么要仔细研究未分类列表的所有中间步骤？这会影响big-o吗？
好吧，这是一个很好的问题，但是您正在迭代模式中思考。在激活寄存器中，您必须知道Mergesort以递归模式破坏了数组。我的意思是，您以这种方式有Mergesort：
[3,7,4,8,10,9] --> [3] [7] [4] [8] [10] [9]
这是在一组递归模式下完成的，但是如果您以迭代模式调用并用循环将所有这些值分开，则在功能中没有状态，因为您有一组分开但您的寄存器在哪里包含合并所有这些值的值？您必须考虑寄存器模式保存值，然后停用寄存器并合并这样做的值：
[3] [7] [4] [8] [10] [9] ---> [3, 7] [4,8] [9, 10]
您注意到更改吗？这是您需要递归电话的方式，因为您分解了先前的状态并一次又一次合并。我希望我能帮助您。
您需要递归分裂，不仅要将此列表分解为订书钉，而且还需要控制列表的合并，因为您在对sublists进行分类后重新浏览"备份"。
如果您一次迭代地分开一个元素，然后一次将它们合并回一个元素，则最终会得到O( n 2 (算法而不是o( n log( n ((
为什么您不仅要开始获取初始的未分类列表并立即将其分解为1个元素列表的基础案例，然后再通过一次组合两个1个元素列表来备份？
从1个元素列表的基本案例开始(运行(是如何完成迭代合并排序的方式。它的速度稍高，因为未将索引对并从堆栈中弹出。大多数库都使用自下而上的合并排序的一些变化。Wiki文章包括伪代码：
https://en.wikipedia.org/wiki/merge_sort#bottom-up_implementation