在C#中定义多个同名方法时，编译器必须根据调用时传递的实参来唯一确定应该执行哪个方法版本。这一过程被称为重载解析，它远比简单的“参数个数不同”要复杂。方法的签名由方法名、参数个数、参数类型以及参数修饰符构成，但不包括返回值类型和参数名称。因此，仅返回值不同而参数列表相同的方法无法构成重载。编译器在区分重载时，会首先检查参数个数是否一致，然后逐一比对参数类型的兼容性，并评估隐式转换的代价，最终选出最合适的方法。理解这些规则，是避免调用歧义的关键。
参数列表是重载区分的首要依据
方法重载的最直观区分方式是让每个重载版本的参数个数不同。假设我们定义了两个名为 Compute 的方法，一个接收两个 int 参数，另一个接收三个 int 参数。调用时传递的实参个数直接决定了调用目标，编译器不会产生任何犹豫。但个数并非唯一因素，参数类型的变化才是重载设计中的常态。例如，一个方法接受 int 类型，另一个接受 double 类型，调用 Compute(5) 会匹配 int 版本，因为字面量 5 是 int 类型，不存在转换开销。而调用 Compute(5.0) 则会匹配 double 版本，因为 5.0 字面量默认为 double。
当类型不同但存在隐式转换时，区分规则会变得更微妙。如果同时存在 Compute(long value) 和 Compute(double value)，那么调用 Compute(5) 会如何？字面量 5 是 int，可以隐式转换为 long 和 double，此时没有直接匹配的 int 版本。编译器会应用“更好转换”规则：int 到 long 的转换优于到 double 的转换，因为 long 也是整数类型，并且不会产生精度损失。这个例子说明，隐式转换的优劣顺序是重载决策的核心，编译器会优先选择转换代价更小的版本。
除了参数个数和类型，参数修饰符也参与方法签名的构成。ref、out 和 in 修饰符会让参数在元数据层面表现为不同的类型，因此它们也是区分重载的一部分。也就是说，可以同时定义一个接收 int 的方法和一个接收 ref int 的方法，它们被视为不同的签名。调用时，如果实参传递的是具有 ref 修饰的变量，则匹配 ref 版本；如果传递普通值，则匹配无修饰符的版本。params 关键字则略有不同，它不改变签名本身，但会影响重载解析时是否为参数数组展开进行匹配，并且非 params 数组版本在参数数量相同时具有更高的优先级。
重载解析中的优先级与“更好转换”规则
当方法的参数类型不能完全匹配时，C#编译器会使用一套复杂的“更好转换成员”规则来选出最佳候选。其核心思想是，如果一个重载版本中的所有参数类型转换都不比另一个版本差，并且至少有一个参数转换严格优于另一个，则该方法就是更好的选择。判断转换优劣时，存在明确的层次：从派生类转换到基类优于从基类转换到派生类；数值类型之间，无符号到有符号的转换优于有符号到无符号的转换；从 int 到 long 优于到 float 或 double。理解这套层次有助于预测编译器行为。
来看一个典型的例子：
void Show(int x) { Console.WriteLine("int"); }
void Show(long x) { Console.WriteLine("long"); }
void Show(float x) { Console.WriteLine("float"); }
Show(10); // 输出 int，因为10是int，直接匹配
Show(10L); // 输出 long，10L是long，直接匹配
Show(10F); // 输出 float
// 没有int版本的调用：
Show(5); // 如果有int和long重载，则选int；如果没有int，有long和float，则选long，因为long转换更好
在示例中，如果去掉 int 版本，调用 Show(5) 将在 long 和 float 之间选择。由于 int 到 long 是扩展整数转换，且没有精度损失，而 int 到 float 虽然隐式但可能丢失精度，因此编译器判定 long 版本为更好的重载。若同时存在 long 和 ulong，则 int 到 long 优于到 ulong，因为从有符号到有符号的转换优先级高于有符号到无符号。
命名参数和可选参数的引入使得重载区分更加复杂。C# 4.0 开始支持命名实参和可选参数，这使得原本通过参数个数来区分重载的方案需要重新评估。假设有两个重载：void Process(int x, int y = 0) 和 void Process(int x)。当调用 Process(5) 时，两个重载都满足条件：第一个因为第二个参数有默认值，只需传递一个实参；第二个则只有一个参数。这种调用会产生歧义，编译器无法决定使用哪一个，会直接报告“调用不明确”编译错误。因此，在设计带有可选参数的重载时，必须确保调用时不会出现二义性，通常的做法是避免让一个重载成为另一个重载的“可用更少实参”版本。
泛型方法重载与类型推断的交互
泛型方法同样可以参与重载，而且区分规则因类型推断变得更加灵活。当存在一个泛型重载和一个非泛型重载时，如果实参能够精确匹配非泛型版本，编译器会优先选择非泛型方法，因为非泛型方法被视为“更具体”。例如：
void Print<T>(T value) { Console.WriteLine($"泛型: {value}"); }
void Print(int value) { Console.WriteLine($"int: {value}"); }
Print(10); // 输出 int: 10，非泛型优先
Print("hello"); // 输出 泛型: hello，因为字符串没有非泛型重载
若多个泛型方法同时存在，类型推断的结果会决定哪个重载更合适。例如，定义 void Fire<T>(T arg, T arg2) 和 void Fire<T>(T arg, string arg2)，调用 Fire("a", "b") 时，第一个泛型方法推断出 T 为 string，两个参数都匹配；第二个方法同样推断出 T 为 string，且第二个参数是 string 也匹配。此时两个重载都有效，编译器会进一步比较参数的具体度。第二个重载的第二个参数固定为 string，比第一个的泛型版本更具体，因此第二个被选为更好重载。这体现了泛型重载决策中“具体类型优先于泛型类型参数”的原则。
泛型约束也会影响重载区分。当存在多个具有不同约束的泛型方法时，若实参类型满足更严格约束的那个方法，编译器将优先选择它。比如一个重载要求 where T : class，另一个要求 where T : struct，传入引用类型会调用前者，传入值类型会调用后者，因为只有满足约束的重载才会进入候选集。需要注意的是，重载解析发生在类型推断完成之后，因此泛型约束可以帮助过滤掉不兼容的候选，从而协助选出正确的方法版本。
方法重载是C#多态性的基础之一，合理运用能够提升API的易用性和可读性。但重载设计必须遵循“调用唯一性”原则，避免产生歧义。在编写重载方法时，要清晰理解参数修饰符、隐式转换、可选参数以及泛型约束所带来的影响；如果发现编译器报告调用不明确，通常需要调整方法签名或改用不同方法名来消除歧义。掌握这些区分规则后，你可以自信地在日常开发中使用重载，而不会陷入编译器错误带来的迷惑。