为什么直接调用 Sort()
会报错“无法比较数组中的元素”
因为
List<t></t>或数组的
Sort()方法默认依赖
T实现
IComparable（或
IComparable<t></t>），如果类没实现，运行时就抛
InvalidOperationException：“Failed to compare two elements in the array.”
这不是编译错误，所以容易漏掉——直到排序时才崩。
只实现IComparable（非泛型）：需在
CompareTo(object obj)里手动做类型检查和强制转换，易出
NullReferenceException或
InvalidCastException优先实现
IComparable<t></t>：编译期类型安全，避免装箱，性能更好 若类是
sealed或你无法修改源码，改用
Comparison<t></t>委托或
IComparer<t></t>外部比较器更合适
IComparable<t></t>
的 CompareTo()
怎么写才不出错
核心原则：返回负数表示“小于”，0 表示“等于”，正数表示“大于”。别反了，否则排序结果颠倒。
常见错误是 null 处理不当。比如比较字符串字段时，直接调
name.CompareTo(other.name)，一旦
other为
null或自己字段为
null就炸。 先判断
other是否为
null：按约定，
null视为比任何非空对象“小”，所以返回
1字段级比较用静态方法：如
string.Compare(this.Name, other.Name, StringComparison.Ordinal)，它天然处理
null多个字段排序？按优先级链式判断：先比
Priority，相等再比
CreatedTime，用
??或
?.CompareTo()避免空引用
public int CompareTo(MyItem other)
{
if (other == null) return 1;
var c1 = Priority.CompareTo(other.Priority);
if (c1 != 0) return c1;
return CreatedTime?.CompareTo(other.CreatedTime) ?? (other.CreatedTime == null ? 0 : -1);
}
实现 IComparable
后，OrderBy()
还用得上吗
能用，但没必要。LINQ 的
OrderBy()默认不走
IComparable，它内部用的是
Comparer<t>.Default</t>—— 而这个默认比较器，**恰好会 fallback 到
IComparable<t></t>（或
IComparable）**。所以实现了，
OrderBy()就自动生效。
list.OrderBy(x => x)会触发你的
CompareTo，等价于
list.Sort()但
OrderBy(x => x.Name)是按
Name排，跟你类上的
IComparable无关——那是另一层投影逻辑 如果想让
OrderBy(x => x)和
Sort()行为一致，必须确保
CompareTo的逻辑和你期望的“自然顺序”完全匹配
排序不稳定？可能不是 IComparable
的锅
.NET 的
Array.Sort()和
List<t>.Sort()</t>是**不稳定排序**（相同键值的元素相对位置可能变），而 LINQ 的
OrderBy()是**稳定排序**。这跟
IComparable实现无关，是底层算法差异。 如果你依赖“同等优先级的项保持原有顺序”，别用
Sort()，改用
OrderBy()自定义
CompareTo返回
0的逻辑必须严格一致：比如两个对象的
Priority和
CreatedTime都相等，才返回
0；若只比了
Priority就返回
0，那后续字段差异就被忽略了，排序看起来“乱” 调试时可临时加日志：在
CompareTo里打点，看实际传入的
other是谁，确认比较路径是否符合预期 真正容易被忽略的，是
CompareTo中对
null字段的防御性处理，以及“相等判定”是否覆盖了所有业务意义上的等价情况——少一个字段，排序就可能漏掉关键区分维度。
