反射调用重载方法的关键在于获取方法时就明确参数类型签名，而非调用时动态匹配；Java/C#均要求getMethod阶段严格对应类型，否则抛异常。
反射动态调用重载方法，核心不在“运行时传什么参数”，而在于“获取方法时就明确要哪个签名”。外部参数的动态性（比如用户配置、json字段、http请求体）容易让人误以为该靠参数类型自动匹配，但实际 java 和 c# 的反射机制都要求：方法对象必须在 调用前就精确绑定到特定参数类型，否则会抛异常或选错重载。
关键原则：方法获取与参数类型严格对应
重载方法的区分发生在 getMethod() 或 getDeclaredMethod() 阶段，不是 invoke() 阶段。例如：
-
Java 中：
clazz.getDeclaredMethod("save", String.class)和clazz.getDeclaredMethod("save", Integer.class)是两个完全不同的 Method 对象；传new Object[]{"abc"}给前者能成功，给后者直接抛NoSuchMethodException。 -
C# 中：
type.GetMethod("Process", new[] { typeof(string) })与type.GetMethod("Process", new[] { typeof(int) })返回不同 MethodInfo；即使你传new object[] { 42 }给前者，也会报TargetParameterCountException或类型不匹配错误。
应对动态参数的三步落地策略
当外部输入不确定是字符串、数字、布尔或 null，又需分发到不同重载方法时，不能靠“猜”，而应结构化映射：
-
先归一化输入类型：把原始数据（如 JSON value、表单字段）转为明确的 .NET Type 或 Java Class。例如用
JsonSerializer.Deserialize<JsonElement>后判断ValueKind，再映射到typeof(string)、typeof(int)等。 -
预建方法签名字典：按常见组合缓存 Method/MethodInfo。例如：
methodMap[("save", "string")] = methodWithString；避免每次重复查找。 -
参数数组构造须严格对齐：invoke 时传入的 object[] 不仅长度要对，每个元素也得是目标参数类型的实例。int 参数不能传
null，string 参数不能传42；必要时做显式转换：(object)(int)val或Convert.ToString(val)。
绕过重载陷阱的替代方案
若重载逻辑本质是“同名不同行为”，更健壮的做法是放弃重载，改用显式分发：
- 定义统一入口方法，如
public void execute(String action, Map<String, Object> params)，内部用 if-else 或策略模式路由。 - 用
dynamic（C#）或invokedynamic（Java 15+）延迟绑定，但注意：这仍是运行时解析，不改变重载选择逻辑，且牺牲编译检查和性能。 - 生成委托（C#
CreateDelegate）或 Lambda（JavaMethodHandle），把方法绑定提前到初始化阶段，调用时只传参，不查方法。
真正解决逻辑分发难题，不靠反射多聪明，而靠把“动态”收口成“可枚举的确定类型”，再让反射成为稳定执行通道。否则，每次参数微变都可能触发 NoSuchMethod 异常，调试成本远高于设计一层薄薄的分发层。
