C#排序性能深度实测：内置Sort API与手写算法选型指南

先聊个现象。我见过不少做上位机、做管理系统的朋友，一遇到界面卡顿就怀疑数据库慢，查了一圈发现瓶颈在内存里对一堆自定义对象做排序。那时候用的还都是随手写的冒泡或者List.Sort，问题倒也能解决，只是数据量一上来，差别就是秒开和转圈的差距。C#的排序性能这个话题看着基础，真较真起来水很深，牵扯到算法本身、运行时实现、数据特征、还有框架版本。这篇就把我实测过的东西完整摆出来，包括原生API的底细、经典手写算法的真实表现，以及实操里最有用的选型建议。

1. 排序场景到底该怎么定义，我为什么做这次对比

1.1 对比的核心目标与预设

我需要先说明白这次对比的地基是什么。排序性能不能脱离场景谈，脱离数据量的排序对比都是耍流氓。

我这次的核心目标是回答三个问题:

• .NET里现成的排序API（Array.Sort、List.Sort、LINQ的OrderBy）到底谁最快，各自适用什么场景。
• 手写经典算法（冒泡、选择、插入、希尔、快排、归并、堆排序）和框架内置排序差多少。
• 面对不同特征的数据（随机、有序、逆序、大量重复），算法的表现是不是和我们书上学的一致。

有意思的是，很多教科书排序性能的结论停留在理论层面，实际在JIT编译后的表现会和理论有出入。比如快排在重复元素很多的数据上会退化得非常难看，而三路划分可以解决这个问题，但是CLR内置排序是否做了优化，需要实测才能下结论。

另外补充一个容易忽略的点：很多人觉得.NET 8、.NET 9只是性能小幅提升，但排序相关的运行时改动其实相当明显。这次对比我用了.NET 8环境，部分结论在.NET Framework 4.8上会有差别，我会在对应的地方明确指出。

1.2 测试环境与基准方法

先交代测试平台，方便大家复现和参考：

关键点在于，BenchmarkDotNet不是简单的Stopwatch计时，它会做预热、防止JIT优化、统计GC分配。很多人自己用Stopwatch测，测出来的结果波动巨大，根本原因是没做预热，第一轮JIT编译的时间被计进去了。

排序对象选择的是int数组和一个自定义的Person记录（包含Id和Name），因为实际项目里很少单纯排int数组，大多数是排对象列表。自定义对象的排序涉及比较器的调用开销，比值类型排序复杂得多。

比较器方面我没有额外优化，用的是默认的Comparer.Default，这也是绝大多数项目里的真实使用方式。

2. C#排序方法全景：框架提供的牌面到底什么样

2.1 原生排序API家族盘点

C#里现成能用的排序入口，实际就四大类，很多人搞不清它们底层的差别：

Array.Sort：最直接的排序方法，底层用的是内省排序（Introspective Sort）。它会在快排、堆排序、插入排序之间动态切换。面对大规模数组，它会限制递归深度，超过一定深度后切换为堆排序，防止快排在坏情况下退化成O(n²)。这是.NET Framework时代就成熟的设计。

List.Sort：内部其实就是调用Array.Sort，因为List内部封装了一个数组。差别在于List的索引器访问有一些边界检查开销，通常可以忽略不计。

LINQ的OrderBy：这是懒加载的排序。它不会立即排序，而是等到你调用ToList()、ToArray()或者foreach去遍历的时候才真正执行。底层使用的是稳定的快速排序（稳定快排在.NET Core 3.0之后就改成了专门实现，数据量大时会采用多趟归并的思路保证稳定性）。

LINQ的OrderByDescending：和OrderBy的区别只是比较器反转，底层逻辑一样。

很多人有个误区：总觉得LINQ很慢，实际上OrderBy的底层实现经过深度优化，在数据量中等（千级到十万级）的时候和Array.Sort差距非常微小，很多时候反而是写起来最不容易出错的选择。

2.2 各种内置方法实测下来到底能差多少

我用随机int数组实测了不同规模下的排序，单位是微秒（数值越小越快）：

从结果能看出来一个趋势：数据量到100万级别的时候，OrderBy比Array.Sort慢了大约40%。这个差异主要来自LINQ需要额外分配内存来存放索引或者分组结构，还要处理延迟执行的状态机。

但是！这里的对比有个隐藏前提：大家都调用了ToArray或者ToList。如果只是把OrderBy的结果拿去foreach，那OrderBy底层走的是分区迭代逻辑，内存占用会更低，整体体验不会差太多。

实际项目中，如果排序后还要做复杂的后续操作，建议排序后就物化（Materialize）成数组或列表，不要留着懒加载的IOrderedEnumerable到处传，否则可能重复排序多次，这是常见的隐性问题。

这里说一下我踩过的坑：有次写报表逻辑，把一个OrderBy的结果传给两个下游方法，每个方法都foreach了一遍，等于同一个数据排了两次。数据量5万条，界面卡了快两秒才反应过来是这个问题。

3. 手写经典排序算法的横向实测，谁在裸泳一测便知

3.1 经典算法实现要点（含注意事项）

为了横向对比，我手写了八种经典排序，每个都按教科书基准实现，没有额外做工程优化：

• 冒泡排序：标准双层循环，相邻比较交换。
• 选择排序：每轮找最小值的下标，最后才交换。
• 插入排序：从前往后构建有序序列，逐个插入。
• 希尔排序：gap从n/2开始递减，每个gap做插入排序。
• 快速排序：固定选最后一个做pivot，双指针扫描，递归实现。
• 三路快排：分成小于、等于、大于三个区，处理重复元素。
• 归并排序：自顶向下递归，需要额外数组做merge。
• 堆排序：建大顶堆后每次把堆顶换到末尾，再下筛。

实际写代码的时候有两点要特别注意。

快速排序的递归深度在极端情况下可能超过栈空间。虽然.NET默认栈空间是1MB，但当数据量到10万以上且pivot选得烂（比如已经有序的数据），递归深度可能会上万层，直接爆栈。所以生产环境里必须在递归前检查区间大小，小于某个阈值（比如16）改用插入排序。

归并排序一定要传入额外的临时数组做合并，不能在merge里反复new数组。我曾经见过有人在递归函数里new临时数组，结果100万条数据跑了十几秒还没结束，GC直接把CPU吃满，这种问题必须先讲明白。

3.2 实测结果与理论值的碰撞

以下是在完全随机的100,000个int数据上的排序成绩（单位毫秒）：

随机数据下，快排和归并都在毫秒级，差距其实很小。真正让人惊喜的是希尔排序24毫秒的成绩，作为O(n log n)和O(n²)之间的过渡算法，这个成绩相当能打，而且完全不占额外内存。

但请注意，这个成绩不能完全代表算法的优劣。固定选最后一个元素做pivot的快排有一个致命软肋：对已经有序的数组排序时表现是灾难性的。我实测了对100,000个已经升序排列的数据做快排，耗时直接冲到6,480毫秒，比随机数据慢了400倍。这个数字很值得记在心里。

3.3 算法在不同数据分布下的表现（这里有几组值得警惕的数据）

排序性能不只是看数据规模，还得看数据本身的秩序。我专门测了三类特殊数据：完全有序、完全逆序、大量重复（只有0到9十个值循环）。

上面这张表能读出很多信息。

固定pivot的快排在升序数据上彻底崩盘，原因是每次选最后一个元素做pivot，而升序数据的最后一个元素正好是最大或最小值，导致分区极度不平衡，递归深度退化成O(n)。这就是我前面说的"必须做优化"的原因。

三路快排在重复数据上惊艳全场，2毫秒完成排序，因为它把等于pivot的元素集中处理，不再参与后续递归，大大缩小了递归区间。

归并排序和堆排序是四种数据形态下最稳定的，不管什么输入，时间都在16到22毫秒之间波动。这让它们很适合做对稳定性要求高的场景，或者对数据特征无法预判的场景。

希尔排序也很稳，虽然理论上最坏情况是O(n²)，实际上面对升序和重复数据表现都很好。gap的选择对结果影响很大，后面再细聊。

4. 为什么Array.Sort比你手写的快排还快，内置排序的工程机密

4.1 内省排序机制到底做了什么

很多人好奇，我手写的快排已经17毫秒了，Array.Sort还要更快一些，它到底做了哪些黑魔法？

Array.Sort底层实现是内省排序，大致逻辑是：

1. 分区深度低于某个阈值时，走快排。
2. 递归深度超过2 * log2(n)时，切换成堆排序，防止最坏情况。
3. 分区后的子数组长度小于16时，用插入排序收尾。

这个策略有它的道理。快排在大部分情况下最快，但存在理论上的最坏情况O(n²)。堆排序保证了最坏情况也是O(n log n)。插入排序在数据量小的时候常数极小，因为它利用了CPU缓存局部性，顺序访问比跳跃访问快得多。

实际上还有一个极其重要的细节：Array.Sort是原地排序，几乎不分配额外内存。这意味着它对GC的影响几乎为零，而手写归并排序在100万数据时可能需要分配几MB的临时数组，对内存压力完全是两个量级。

4.2 为什么稳定性上OrderBy反而更适合业务场景

稳定性是什么意思？就是排序前相等的两个元素，排序后相对顺序会不会改变。Array.Sort是不稳定排序，数据量小的时候实际用的是快排，两个相等的元素可能被交换位置。

OrderBy不同。微软文档明确说它是稳定排序。这意味着用OrderBy排一个对象列表时，如果两条记录的Id相等，它们的原始顺序会被保留。

这个特性在什么场景下最有用？比如你有一个列表，先按创建时间排好序，然后想按类型分组但保持组内时间顺序，这时候直接对类型做OrderBy就能保留之前的顺序。如果用Array.Sort，分组后原先的时间顺序就被打乱了。

实际项目中我的经验是：业务逻辑排序（管理系统列表、报表数据）优先用OrderBy，简单直接且稳定；底层性能敏感的场景（比如写排序组件、处理大批量数值）用Array.Sort或Span.Sort。

4.3 Span.Sort存在的意义以及什么时候该用

提到Span.Sort就绕不开。.NET Core 2.1之后引入了Span，它在栈上或者托管堆上维护连续内存，排序时避免了数组的边界检查等额外开销。

我用100万个int做了测试，Span.Sort耗时约33毫秒，比Array.Sort的36毫秒快了大概8%。这个优势在内存操作密集的场景下会被放大。

Span.Sort更适合什么时候用？如果你从网络接收二进制数据、在解析文件缓冲区时直接对一段内存排序，不需要把数据复制成数组再排。这种情况下Span的免复制特性比微弱的性能提升更值钱。

需要注意Span是ref struct，不能存到堆上，不能用作类的字段，也不能在async方法里跨越await使用。刚开始不熟悉的人容易踩编译错误，多用几次就习惯了。

5. 自定义对象排序以及比较器的隐藏开销

5.1 对象排序实测和int排序差距有多大

前面测的都是int，实际开发中排得更多的其实是对象。我把排序对象换成Person（含Id和Name字段），重新测了一遍。

定义如下：

csharp复制public class Person {
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
}

对10万个Person对象按Id排序，结果如下：

对比int排序，耗时翻了几倍。差别主要来自比较器调用是间接调用（不是直接内联的数值比较），还有对象数组本身存放的是引用，缓存不友好，每次比较都需要解引用访问堆中的实际对象。

这引出一个重要建议：如果你的排序对象是个复杂的类，可以尝试把需要排序的关键字段抽出来，做成（int key, object value）的结构体数组，按key排序后再映射回去。这是典型的"键索引排序"思路，在.NET里用得好能带来数倍提升。

5.2 比较器内部原理与编写优化

C#排序默认走的是Comparer.Default，这个默认比较器最终会对实现IComparable的类型调用CompareTo方法。数值类型走的是JIT直接内联的代码路径，效率极高。自定义类型如果没有实现IComparable接口，则会走反射路径？其实不会，.NET会生成比较器的委托，但如果是老的.NET Framework版本或者没做优化，确实可能慢。

实际操作里，有不少朋友会把比较逻辑写在lambda表达式里传给List.Sort：

csharp复制list.Sort((a, b) => a.Id.CompareTo(b.Id));

这种写法确实简洁，但每次排序都会触发一次委托调用，开销比直接调用CompareTo稍高。测量下来10万个对象按Id排序会慢大约6-8毫秒，数据量过百万就比较明显了。

如果想极致优化对象排序，可以这样处理：

1. 定义一个实现IComparer的比较器类，复用实例。
2. 用结构体实现IComparer接口，这样比较调用可以被JIT内联。
3. 排序前把Person对象里的排序字段缓存到一个int数组，排序这个数组再重新映射原数组。

第2条实际上有一个经典的.NET性能优化技巧"struct comparer"，具体做法是：

csharp复制public struct PersonIdComparer : IComparer<Person> {
    public int Compare(Person? x, Person? y) {
        return x!.Id.CompareTo(y!.Id);
    }
}

因为泛型约束TComparer是值类型，JIT能为每个具体类型生成专用代码，把接口调用直接内联展开，省去虚调用开销。用这个技巧，对象排序的性能可以提升10%到20%，在百万级数据上效果更明显。

但对一般项目而言，我建议先把逻辑写对写清楚，真的变成热点再追求性能。排序通常不会是系统瓶颈，把代码写得可读才是优先考虑的。

6. 实例工程复盘：控制台程序完整实现与结果解读

6.1 从零到一的基准项目搭建

如果你也想自己跑一遍，这里给出一个简化的非BenchmarkDotNet版测试程序框架，方便理解排查思路。

csharp复制using System.Diagnostics;

var dataSize = 100_000;
var random = new Random(42);
var baseData = new int[dataSize];
for (int i = 0; i < dataSize; i++) {
    baseData[i] = random.Next(0, 100_000);
}

var sw = Stopwatch.StartNew();
var sorted = baseData.OrderBy(x => x).ToArray();
sw.Stop();
Console.WriteLine($"LINQ OrderBy: {sw.Elapsed.TotalMilliseconds:F2} ms");

如果你只是跑一遍，可能发现结果波动较大，比如同样的代码这次17ms，下次22ms。这不一定是你写错了，而是JIT暖身不同、CPU频率变化、后台线程调度都会影响结果。严谨的做法是预热几次再计时，取多轮最小值或者平均值。

我自己写的完整测试程序里还会做以下步骤：

1. 先跑一次所有方法，触发JIT编译后再开始正式记录。
2. 每轮测试前重置数据集，避免排序后数据变成升序影响下一轮。
3. 多次测量取中位数。

用BenchmarkDotNet就不用操心这些，但它在项目里会额外引入不少依赖。简单的脚本验证手写Stopwatch完全够用，关键是预热和随机种子固定。

6.2 数据结果合理性的校验方法

测完结果要先验证一个基本问题：排序结果真的对吗？我见过太多人测试性能时完全不校验结果，快排出了bug还是排对了大部分数据，测试成绩照样好看。

我的做法是在每次排序后做断言：

csharp复制for (int i = 1; i < sorted.Length; i++) {
    if (sorted[i - 1] > sorted[i]) {
        throw new Exception($"排序错误，位置 {i - 1} 和 {i} 顺序不对");
    }
}

这个步骤虽然简单，但每次跑之前都加上，能帮你排除"算法实现有bug，只是碰巧跑了很快"的假象。

另外，我还建议在排序前后记录GC的AllocatedBytes，用来观察算法的内存开销。前面已经提到，虽然100万int排序时间只差几十毫秒，但内存分配可能差出几MB，这在长时间运行的服务端程序中比速度更重要。

6.3 顺手整理一份"数据量vs算法选择"对照表

为了落到实操，我把日常经验整理成了一份选型速查表：

这张表不是万能真理，但能解决我遇到过的大部分排序选型困境。

7. 实操中必须绕开的几个深坑（一般人不会写出来）

7.1 稳定性误判导致的数据错乱

这个坑是我接手一个老系统时才撞上的。当时有个页面展示商品列表，逻辑是先按销量倒序排，再按上架时间倒序。原来的写作者用了List.Sort，并且二次排序时把按销量排好的顺序弄乱了。用户看到的列表里，同一上架时间的商品销量排序是乱的。

原因是List.Sort是不稳定排序。商品销量相等时，它们之间上架时间的相对顺序可能被重新打乱。如果这里用OrderBy连续排两次，第一次排序的相对顺序就能被第二次保留，问题就消失了。

使用经验：只有当你的比较器能完全决定元素唯一顺序时，不稳定的Array.Sort才安全。否则请用OrderBy这类稳定排序。

7.2 可变对象在排序后继续修改导致的结构损坏

这也算一个排序相关的冷门坑。有些排序算法在排序过程中会缓存部分元素的信息（比如快排的pivot值），如果排序过程中比较器内部访问的对象属性发生变化，会导致排序结果错乱和索引越界。

实操中更常见的是排队列的时候改属性。比如对一组订单按金额排序，如果在排序的Comparer里顺手改了订单的状态字段，下一次比较时金额可能已经变了，最后数组里数据顺序是乱的，但程序不会报错。这个问题非常隐蔽，排查起来需要半天。

规避方法也很简单：排序期间绝对不要在Comparer里修改对象状态；如果一定要在排序后改动数据，先排序完再做。

7.3 string排序比想象中要慢

网热搜里有"字符串排序"，这个确实值得单独说。

字符串排序的开销远超int、double这些值类型。因为字符串的CompareTo需要逐字符比较，而且字符串对象分散在堆上，缓存完全不友好。我实测过对10万个随机字符串排序：Array.Sort耗时约120ms，而同样的int排序只要3ms，差了40倍。

如果确需对大量字符串排序，有两个思路：

1. 如果字符串前缀重复度高，先排序它们的哈希值？这里哈希排序不稳定，相同哈希的字符串仍需二次确认，反而更慢。
2. 更实用的是避免直接排序原字符串数组，可以考虑对字符串的长度和首字符建立索引来排序，但大多数场景下不值得。

顺序执行字符串CompareTo是O(L)的复杂度，L是字符串平均长度。对100万条平均长度20的字符串排序，最坏情况是20次字符比较乘以排序复杂度，这也是为什么字符串排序会成为瓶颈。

7.4 并行排序不要脑热就上

PLINQ的AsParallel().OrderBy()看起来很诱人，但排序不是纯计算密集型操作，并行化的收益受限于内存带宽和线程调度开销。

我实测100万int排序，AsParallel().OrderBy().ToArray()耗时80ms，Array.Sort要36ms，并行版本反而慢了一倍多。数据量低于千万级别，并行排序的负载均衡开销会抵消所有加速收益。

如果排序对象是自定义类或者字符串，并行排序的收益会更差。因为比较器的访问往往需要锁或者同步（虽然这里Comparer是线程安全的，但每个线程访问的数据如果共享，会引起缓存行颠簸），反而阻碍性能。

稳妥的建议是：单线程排序打底，真的遇到千万级数据的排序再看并行。

8. 高版本.NET新特性对排序的影响以及实测补充

8.1 .NET 8和.NET 9在排序上做了什么变化

.NET紧跟时代也更新了排序相关实现。只是大部分业务开发者感知不到，因为从不看运行时源码变化。

.NET 8的Array.Sort引入了一个重大的改动：对数值类型（int、long等）的特殊路径排序得到加强。实测同样的100万int随机数组，在.NET 7上是43ms，而在.NET 8上是36ms，提升了约16%。这来自对比较器调用的内联优化和无边界检查的分区循环。

.NET 9更进一步优化了插入排序的逻辑，在数组已经基本有序时会有更激进的提前退出机制。在现实中，人和系统产生的数据往往带有一定顺序性，所以这个改动对业务场景可能有正向影响。

顺带一提，.NET 8里还引入了CollectionsMarshal.AsSpan(list)这个API。它可以把List的内部缓冲区直接暴露为Span，这样你就能对List做排序而不产生任何额外副本：

csharp复制var list = new List<int>();
// ...填充数据
var span = CollectionsMarshal.AsSpan(list);
span.Sort();

这个操作本来需要list.Sort()或list.CopyTo再排序，现在可以直接原地操作Span。需要特别注意的是：Sort之后List的版本号不会更新，如果在排序过程中有其他代码正在枚举list，可能导致不可预知状态。务必不要在foreach循环里去调它。

8.2 有没有必要手写高难度排序

先给结论：绝大多数情况下没必要手写排序，内置实现足够好。

我自己手写就是出于教学目的和特殊场景需要：

• 三路快排处理大量重复数据时确实比内置快，但内置排序对稳定性的要求不同。
• 归并排序是稳定的，如果既要稳定排序又要代码级别可控，没有内置的稳定原地排序。
• 手写排序时能体会到底层细节，对排查性能问题帮助很大。

如果你只是一般项目里用排序，老老实实OrderBy和Array.Sort选一个就行。把省下的时间花在业务逻辑上更有价值。

9. 性能对比之外，排序代码的一些宏观设计思考

9.1 排序结果如何影响后续操作效率

很多人忽略排序的“副产品”价值。一个排好序的数组，可以做二分查找，可以在O(log n)时间内找到上下界。在编程竞赛和实际系统优化中，“先排序再处理”是一句经典的算法设计格言。

举个例子：你要在一堆订单中找金额最大的10个，如果全部排序需要O(n log n)。更好的做法是维护一个大小为10的最小堆，每个元素和堆顶比较，大于堆顶就替换并堆化，整体复杂度只有O(n log 10)，等于O(n)。这就是热搜词里“c++ 不排序的情况下取得一个vector中最小的十个元素”的同类问题。

C#中对应的做法就是PriorityQueue<TElement, TPriority>，在.NET 6之后内置了。这种场景不排序反而比排序快得多，大数据量下差距在几十倍以上。

9.2 自定义类库中如何把排序做得更可靠

如果你在写一个公共类库，别人会拿你的类去排序，最好做到以下几点：

1. 实现IComparable让默认比较器直接生效。
2. 提供CompareTo时保证自反性、对称性、传递性。
3. 重写Equals和GetHashCode保持与CompareTo一致，否则使用HashSet或Dictionary时可能出现严重bug。

这最后一条经常被忽略。有个经典例子：两个Id相同的订单，CompareTo返回0，Equals却返回false（因为还比较了其他字段），当使用这类对象做Distinct或者HashSet时就会出现明明"相等"却存了两份的诡异结果。我在好几个项目里排查过这种问题，原因就是这个。

9.3 谈谈排序安全边界和异常数据的影响

真实世界的数据总会有脏数据，排序前做防御性处理会让系统的鲁棒性上升一个档次。

比如排序字段为null在C#里默认会排在最前面，但不同比较器的处理不同，自定义的CompareTo也有可能直接抛NullReferenceException。如果你写了一个自定义IComparer，建议在入口处统一处理null：

csharp复制if (ReferenceEquals(x, null)) return y == null ? 0 : -1;
if (ReferenceEquals(y, null)) return 1;

这样排序遇到null不会崩，还能保持可预期的顺序。

另一个常见的问题是NaN。double.NaN的CompareTo结果和普通数值比较完全不同，对包含NaN的double数组排序会得到意想不到的顺序。如果系统允许用户输入任意数字，建议在排序前先清洗数据，把非数值或者超出业务范围的数据拦截下来。

10. 排障实战：遇到"排序很慢"时我用的一套排查流程

10.1 从业务层面缩小排序慢的影响范围

排序性能问题真正到影响用户体验的时候，通常不是排序算法本身不够快，而是某处不知不觉对超大集合做了排序。

我先定位几件事：

1. 排序的是哪一份数据，数据量有多大，来自数据库还是内存。
2. 排序发生在哪个线程，是否阻塞了UI线程。
3. 排序结果是否真的被全部消费，还是说只要其中一小部分。
4. 排序的频率，是用户手动点击还是周期性自动化触发。

有些情况根本不需要排序。比如分页显示，只需要取出当前页的记录再排，不需要整表排好。这也是我在做报表和后台管理系统时经常提醒自己的。

10.2 用ETW和dotnet-trace抓取排序热点

如果需要深入了解排序在进程中的实际耗时，推荐使用dotnet-trace抓真实的运行时事件。很多人一上来就用dotnet-counters看内存，其实对于确定排序热点，dotnet-trace的CPU采样更合适。

基本操作为：

bash复制dotnet-trace collect --profile cpu-sampling -- processId

跑一段时间抓完trace，用PerfView或者dotnet trace report打开，就能看到哪些函数占用的CPU时间最高。如果发现Sort方法和CompareTo方法占用超过20%，排序确实是热点；如果占比只有2%，那么排序本身不是主要问题，换一个方向优化才有实际收益。

我就在一个声称"排序巨慢"的系统里抓到最耗时的不是排序，而是ToString调用。因为界面上有个列表控件，它对每个对象调用了ToString去做显示过滤，数据量一大就把CPU吃满了。排序只是压在骆驼身上的最后一根稻草。

10.3 优化后如何判断收益是否真实

性能优化后必然要做对比验证，这里的关键是保持前置条件一致：

1. 使用同量级、同分布的数据。
2. 在相同的运行时版本下测试。
3. 统计口径保持一致（服务端程序关注P95/P99，客户端程序关注平均耗时）。

另外我踩过的一个坑是：优化后局部代码快了，但总耗时没变。排查后发现瓶颈转移到了下游的foreach处理里，排序节省的10ms完全被下游多出来的缓存失效抵消掉。所以做排序优化一定要从整体链路上看收益，不要只看孤立环节。

11. 项目复盘时的几点体会

排序这个主题看着基础，真要彻底摸透，牵扯到算法分析、运行时实现、内存模型、工程权衡，每个维度都有不少细节。

我自己的体会是：平日里根本不需要手写排序算法，Class库里的Array.Sort经过了数十年工业级打磨，安全性、稳定性和性能的平衡做得很好。但在极端场景和专有场景里，理解排序底层的切换逻辑以及不同算法的内存分配模式，能帮你做出远超经验的判断。

分享给大家一个小建议：无论你在做什么系统，都值得花半小时跑一次类似文中的benchmark，为自己项目里最常用的排序场景建立一组基线数据。以后遇到"系统变慢到底是不是排序引起的"这类问题，直接拿基线说话，比直觉可靠得多。

最后别忘了我反复强调的错误原则：排序前确认数据形态；排序时不要修改对象状态；排序后验证结果的正确性。记住这几条，你踩过的坑会少很多。