ThenBy必须跟在OrderBy或OrderByDescending之后使用，单独调用会编译报错；它仅用于追加次级排序，优先级低于前序排序，支持与ThenByDescending混用，但需注意执行上下文、null安全及数据库兼容性。
ThenBy 必须跟在 OrderBy 或 ThenBy 后面，单独用会编译报错
你写 list.ThenBy(x => x.Age) 直接报错？对的——ThenBy 不是独立排序入口，它只负责“追加次级排序”，前提是前面已经有一个主排序（OrderBy 或 OrderByDescending）。这是最常卡住新手的地方。
常见错误现象：CS1061 'IQueryable，往往是因为漏了前面的 OrderBy，或者误以为 ThenBy 能自己启动整个链式调用。
- 必须以
OrderBy/OrderByDescending开头，后面才能接任意数量的ThenBy/ThenByDescending - 顺序很重要：先写的排序优先级高，后写的只在前一级相等时生效
- 所有
ThenBy链都作用于同一个数据源，不会改变原始集合
多字段混合升降序：用 ThenByDescending 控制某一级倒序
比如“按部门升序，同部门内按薪资降序”，就不能全用 ThenBy。第二级得换 ThenByDescending，否则薪资也跟着升序排，结果就错了。
使用场景：报表导出、列表页默认排序、后台管理数据展示——只要用户说“先按 A 排，A 相同再按 B 从高到低排”，就轮到 ThenByDescending 出场。
-
ThenBy和ThenByDescending可以混用，没有次数限制 - 注意参数类型要和前一级一致（都是
IQueryable或IEnumerable），别把IQueryable链里插个.ToList()中断掉 - 如果用了
AsEnumerable()提前转成内存排序，后续ThenBy就走 LINQ to Objects，不是 SQL 翻译了
示例：
var result = users.OrderBy(u => u.Department).ThenByDescending(u => u.Salary).ToList();
ThenBy 在 IQueryable 和 IEnumerable 上行为不同
数据库查询（IQueryable）和内存集合（IEnumerable）都支持 ThenBy，但背后做的事完全不同——这点不留意，性能或逻辑可能翻车。
性能影响：用 EF Core 写 OrderBy(x => x.Name).ThenBy(x => x.Id)，最终生成的 SQL 是 ORDER BY Name, Id；但如果中间有 .ToList()，后面再 ThenBy 就变成内存里二次排序，数据量大时明显变慢。
- EF Core 6+ 支持大部分
ThenBy组合翻译成 SQL，但嵌套表达式（如x.Address?.City）可能触发客户端求值警告 - 若排序字段为 null，
ThenBy默认把 null 排最前（SQL Server）或最后（SQLite），行为依赖数据库，默认不保证跨库一致 - 字符串排序默认区分大小写，需要忽略大小写时，别用
StringComparer.OrdinalIgnoreCase传给ThenBy（不支持），改用.ThenBy(x => x.Name.ToLower())或数据库函数映射
空引用或属性为 null 时 ThenBy 容易崩
比如 OrderBy(x => x.Manager.Name).ThenBy(x => x.Team.Leader.Name)，只要某个 Manager 或 Team 是 null，运行时直接抛 NullReferenceException。LINQ 不会帮你做空判断。
容易踩的坑：前端传参没校验、数据库允许字段为 NULL、DTO 映射时没设默认值，都会让 ThenBy 在取属性途中挂掉。
- 安全写法是用空条件运算符：
ThenBy(x => x.Manager?.Name)，但注意 EF Core 可能无法翻译?.，需确认版本支持 - 更稳的方式是预处理：先
Where(x => x.Manager != null && x.Team != null)，再排序 - 如果必须保留 null 数据，且要控制 null 排序位置，得用数据库特定写法（如 SQL Server 的
ORDER BY ISNULL(ManagerName, '')），LINQ 层难直接表达
复杂点在于：ThenBy 看似只是加个“再按……排”，但它绑定着执行上下文（是数据库查还是内存算）、依赖前序调用、对 null 敏感、还受表达式可翻译性限制——少一个条件，就可能从一行优雅代码变成运行时报错或查库慢三秒。
