Sort()原地排序且要求元素可比较，OrderBy()返回新序列并支持多级稳定排序，Comparison委托提供灵活自定义排序，Sort()性能更高但不稳定，OrderBy()稳定但有内存开销。
Sort() 直接原地排序，但要求元素可比较
Sort() 是最常用的列表排序方法，它直接修改原 List，不返回新列表。前提是 T 实现了 IComparable（比如 int、string、DateTime），否则运行时抛出 InvalidOperationException。
常见错误现象：
- 对自定义类调用 list.Sort() 报错 “Failed to compare two elements”
- 字符串按 ASCII 排序（如 "Z" ），导致大小写混排不符合预期
实操建议：
- 简单类型直接用：
var numbers = new List{ 3, 1, 4 };
numbers.Sort(); // → {1, 3, 4}
- 字符串忽略大小写：
var names = new List{ "Apple", "banana", "Cherry" };
names.Sort(StringComparer.OrdinalIgnoreCase);
- 自定义类必须实现
IComparable 或传入比较器，不能只靠重载 运算符
OrderBy() 返回新序列，支持复杂排序逻辑
OrderBy() 和 ThenBy() 来自 LINQ，不改变原列表，返回 IOrderedEnumerable，适合链式多级排序或只读场景。注意：它不是就地排序，每次调用都生成新枚举器，且延迟执行。
使用场景：
- 需要保留原始顺序，同时获得一个已排序视图
- 按多个字段排序（如先按 Age 升序，再按 Name 降序）
- 排序逻辑依赖外部变量或条件判断
实操建议：
- 基础用法：
var sorted = list.OrderBy(x => x.Name).ToList();
- 多级排序：
var result = people
.OrderBy(p => p.Age)
.ThenByDescending(p => p.Name)
.ToList();
- 性能注意：如果反复调用
OrderBy 且数据量大，不如先 Sort() 原地排好再复用；LINQ 排序在首次遍历时才真正执行，调试时别误以为“没运行”
用 Comparison 委托做灵活自定义排序
当内置比较逻辑不够用（比如按字符串长度、按某属性的绝对值、按枚举状态优先级），Sort(Comparison 是最直接的方案。它接受一个委托，签名是 int (T x, T y)，返回负数表示 x ，0 表示相等，正数表示 x > y。
容易踩的坑：
- 返回值写反（比如该返回 -1 却返回 1），导致排序结果完全颠倒
- 在比较逻辑中修改对象状态（如调用 Save()），引发不可预知行为
- 忘记处理 null，对可空引用类型直接访问属性会抛 NullReferenceException
实操建议：
- 安全比较字符串长度：
list.Sort((a, b) => {
if (a == null && b == null) return 0;
if (a == null) return -1;
if (b == null) return 1;
return a.Length.CompareTo(b.Length);
});- 按枚举优先级排序（假设
Status 枚举有 Pending=0, Approved=1, Rejected=2）：list.Sort((x, y) => x.Status.CompareTo(y.Status));
稳定性与性能差异：Sort() 更快，OrderBy() 更稳
.NET 的 List 底层用的是 introsort（快排 + 堆排 + 插入排序混合），平均 O(n log n)，最坏 O(n log n)，但它是不稳定排序——相等元素的相对位置可能改变。而 OrderBy() 使用的是稳定的归并排序，相等元素保持原有顺序，代价是额外内存开销和略低性能。
关键判断点：
- 如果业务依赖“相同分数的学生按报名先后排”，必须用 OrderBy() 或手动补索引
- 如果只是数值/时间排序，且数据量超 10 万，Sort() 通常快 20%~30%
- Sort() 不支持异步，无法在 UI 线程安全调用大数据集（会卡界面），此时应考虑分页+后台线程预排序
复杂点往往藏在边界：比如 double.NaN 参与比较时所有比较都返回 false，Sort() 可能把它甩到开头或结尾，而 OrderBy(x => x) 会抛异常；这种细节不查文档很容易漏掉。
