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