OrderBy默认升序且返回新序列不修改原集合；大数据量反复排序需注意性能；升序用OrderBy、降序用OrderByDescending，均需Func<T,TKey>选择器；多字段排序用ThenBy/ThenByDescending链式调用；IQueryable上翻译为SQL ORDER BY，IEnumerable上内存排序；自定义比较逻辑通过IComparer实现。
OrderBy 默认是升序，且不会修改原集合，而是返回新序列；如果数据量大又反复排序，得留意内存和性能开销。
OrderBy 和 OrderByDescending 怎么选
看排序方向：升序用 OrderBy，降序用 OrderByDescending。两者都要求传入一个 Func<T, TKey> 选择器，也就是“按哪个字段排”。别直接传字段名字符串（那是反射写法，慢且不类型安全）。
-
OrderBy(x => x.Age)按Age升序 -
OrderByDescending(x => x.Name.Length)按名字长度降序 - 如果
Age是null的可空类型，OrderBy会把null排在最前（.NET 6+ 默认行为），不是报错
多字段排序要用 ThenBy
OrderBy 只负责第一级排序；第二级及以后必须用 ThenBy 或 ThenByDescending，否则会覆盖前面的排序逻辑。链式调用顺序就是优先级顺序。
- 先按部门升序，再按薪资降序：
.OrderBy(x => x.Department).ThenByDescending(x => x.Salary) - 错误写法：
.OrderBy(x => x.Department).OrderBy(x => x.Salary)—— 第二个OrderBy会丢弃第一个结果，只按薪资排 -
ThenBy必须跟在OrderBy（或另一个ThenBy）之后，单独用会编译失败
OrderBy 在 IQueryable 和 IEnumerable 上行为不同
这是最容易踩坑的地方：对数据库查询（如 EF Core 的 IQueryable<T>）调用 OrderBy，表达式会被翻译成 SQL ORDER BY；但对内存集合（IEnumerable<T>）调用，是纯内存排序，走的是 .NET 的 List<T>.Sort 底层逻辑。
- EF Core 中
OrderBy(x => x.CreatedAt.Date)可能无法翻译，抛出InvalidOperationException: The LINQ expression could not be translated - 想确保翻译成功，优先用简单属性或支持的函数，比如
x.CreatedAt可行，x.CreatedAt.Date在旧版 EF Core 中常失败 - 如果不确定是否翻译，加个
.ToList()强制执行再排序——但注意这会把全部数据拉到内存，大数据集慎用
自定义比较逻辑要用 IComparer
默认字符串排序是区分大小写的，数字排序按值比，但如果要忽略大小写、按拼音、或按业务规则（比如状态 “待处理” IComparer<TKey> 实现。
- 忽略大小写排序：
OrderBy(x => x.Name, StringComparer.OrdinalIgnoreCase) - 自定义状态顺序：
OrderBy(x => x.Status, new StatusComparer())，其中StatusComparer实现IComparer<string> - 注意：
OrderBy的 comparer 参数是第三个参数，别漏掉前面的选择器委托
真正麻烦的不是语法，而是分不清数据是在数据库里还是内存里排；还有人把 ThenBy 当成独立方法乱调用，结果排序完全不对。调试时打个断点看下实际生成的 SQL 或执行前后的元素顺序，比查文档更快。
