编译器未解析到预期扩展方法：Lambda转闭包引发方法匹配异常

这个问题的核心在于C#编译器处理无类型Lambda表达式和显式类型化委托变量的重载解析逻辑差异，以及实例方法与扩展方法的优先级规则，我来拆解一下：

1. 内联Lambda的匹配逻辑 #

当你直接把Lambda作为参数传入appBuilder.Use(...)时，这个Lambda是一个无类型表达式——编译器此时还没有给它分配具体的类型。

而IAppBuilder的实例方法Use(object middleware, params object[] args)要求第一个参数是object，但编译器不能直接将无类型Lambda转换为object（Lambda必须先转换为某个委托类型或表达式树类型）。这时候编译器会转而寻找那些接受委托类型参数的重载，也就是你提到的扩展方法：

public static IAppBuilder Use(this IAppBuilder app, Func<IOwinContext, Func<Task>, Task> handler);

这个扩展方法的第二个参数正好是Func<IOwinContext, Func<Task>, Task>类型，编译器可以把无类型Lambda完美转换为这个委托，因此会优先匹配这个扩展方法。

2. 赋值变量后的匹配逻辑 #

当你把Lambda先赋值给Func<IOwinContext, Func<Task>, Task> handler变量后，这个变量就变成了具体的引用类型实例。此时调用appBuilder.Use(handler)时：

• handler作为引用类型，可以直接隐式转换为object，完全符合实例方法Use(object middleware, params object[] args)的参数要求。
• 在C#的重载解析规则中，实例方法的优先级高于扩展方法——只要存在合法匹配的实例方法，编译器就会优先选择它，而不会去考虑参数类型更精确的扩展方法。

这就是为什么赋值变量后，编译器会选中那个接受object参数的实例方法。

解决方案：强制调用扩展方法 #

如果想在使用变量的情况下仍然调用扩展方法，可以直接通过扩展方法所在的静态类来显式调用：

// 假设扩展方法定义在AppBuilderExtensions类中
AppBuilderExtensions.Use(appBuilder, handler);

这样就能绕过实例方法的优先级，直接触发你想要的扩展方法重载。

内容的提问来源于stack exchange，提问作者daniefer