应使用短路比较、string.Compare 处理 null 和大小写、取负实现降序；注意 Array.Sort 泛型重载匹配、避免 object[]；Comparer.Create 适合轻量场景但需防闭包和性能问题。
怎么写一个能处理多字段、空值、大小写的 IComparer<t></t>
直接继承 icomparer<t></t> 接口不是最难的，难的是让排序逻辑不崩、不反直觉。比如对 person 类按姓名升序、年龄降序、城市忽略大小写排，中间还可能有 null 姓名或 0 年龄——这时候硬写 a.compareto(b) 会出错或结果错乱。
实操建议：
- 别在
Compare方法里直接调string.CompareTo处理可能为null的字段，先用string.Compare(a, b, StringComparison.OrdinalIgnoreCase)，它天然支持null（null排最前） - 多字段组合时，用“短路比较”：第一个字段不等就直接返回；相等才比第二个。别堆
+或乘系数，那会溢出且语义不清 - 如果要倒序（如年龄降序），把比较结果取负：
-Comparer<int>.Default.Compare(a.Age, b.Age)</int>，别写b.Age - a.Age（整数溢出风险）
public int Compare(Person x, Person y)
{
var nameCmp = string.Compare(x?.Name, y?.Name, StringComparison.OrdinalIgnoreCase);
if (nameCmp != 0) return nameCmp;
<pre class="brush:php;toolbar:false;">var ageCmp = -Comparer<int>.Default.Compare(x?.Age ?? 0, y?.Age ?? 0); // 降序
if (ageCmp != 0) return ageCmp;
return string.Compare(x?.City, y?.City, StringComparison.OrdinalIgnoreCase);}
为什么 Array.Sort() 传 IComparer 有时没生效
常见现象：写了自定义 IComparer<person></person>，传给 Array.Sort(persons, comparer)，但数组没变，或者报 ArgumentException: At least one object must implement IComparable。
原因和解法：
- 检查是否误传了
IComparer实例给泛型重载——Array.Sort<t>(T[], IComparer<t>)</t></t>才对；如果传的是非泛型Array.Sort(Array, IComparer)，它只认Array元素实现了IComparable，否则直接抛异常 - 确认泛型参数
T和IComparer<t></t>的T完全一致（比如PersonvsPerson?、引用类型 vs 值类型） - 如果数组是
object[]，别指望IComparer<person></person>能用上——它只能用于Person[]这种强类型数组
Comparer<t>.Create()</t> 比手写类更轻量，但要注意什么
这是 C# 4.5+ 提供的快捷方式，适合一次性、逻辑不复用的排序，比如 LINQ 中临时排序。但它不是万能的，容易踩几个隐性坑。
- 闭包捕获的变量如果在排序过程中被修改（比如外部循环变量），会导致比较结果不稳定——
Comparer.Create((a, b) => a.Name.CompareTo(b.Name))是安全的，但Comparer.Create((a, b) => a.Name.CompareTo(sortByField))就危险 - 性能上，每次调用
Create都新建委托实例，高频排序（如每帧调用）建议缓存到静态字段 - 它返回的是
Comparer<t></t>（继承自IComparer<t></t>），所以能传给Sort、OrderBy等所有接受IComparer<t></t>的地方，兼容性没问题
var nameThenAgeDesc = Comparer<Person>.Create((a, b) =>
{
var nameCmp = string.Compare(a?.Name, b?.Name, StringComparison.OrdinalIgnoreCase);
if (nameCmp != 0) return nameCmp;
return -Comparer<int>.Default.Compare(a?.Age ?? 0, b?.Age ?? 0);
});用 OrderBy 链式调用替代 IComparer？什么时候不合适
LINQ 的 OrderBy(x => x.Name).ThenByDescending(x => x.Age) 看起来更直观，但它本质是创建多个 IComparer 包装器，而且每次调用都生成新序列（延迟执行但内存开销不可忽视）。
- 原地排序场景（如 UI 列表刷新需复用数组引用）必须用
Array.Sort或List<t>.Sort</t>+IComparer，OrderBy返回新IEnumerable，无法复用底层数组 - 大数据量（>10k 条）排序时，
OrderBy默认使用快速排序变体，但内部有额外对象分配；而手写IComparer配合List<t>.Sort</t>是零分配（无 GC 压力） - 需要复用同一套规则做查找（如
List.BinarySearch）时，必须提供IComparer<t></t>实例，OrderBy无法满足
复杂排序真正卡住人的，往往不是语法，而是 null 处理时机、比较方向的一致性、还有泛型擦除后类型匹配这种看不见的约束。写完记得拿含 null、空字符串、负数、大小混排的数据跑一遍，比看十遍文档管用。
