C#泛型Parse方法加可选参数后，Func传递丢失类型推断问题

这个问题的核心在于编译器对方法组转换和直接方法调用的处理逻辑差异，尤其是可选参数在这两种场景下的行为完全不同。

拆解场景背后的逻辑： #

1. 无可选参数时的正常运行逻辑
   你最初的Parse<T>方法签名是T Parse<T>(string value)，它和Select需要的Func<string, DocumentTypesEnum>委托完全匹配——输入一个string，返回DocumentTypesEnum类型。所以编译器可以直接把Extensions.StringEnumerator.Parse<DocumentTypesEnum>这个方法组转换成对应的委托，自然编译通过。

2. 添加可选参数后报错的根本原因
   当你给Parse<T>加上bool ignoreCase = false后，这个方法的实际编译后签名是T Parse<T>(string value, bool ignoreCase)——可选参数只是C#的语法糖，编译后依然是两个参数的方法。

   而Select需要的Func<string, DocumentTypesEnum>只接受一个参数的方法。此时你直接传递方法组Parse<DocumentTypesEnum>时，编译器需要找到一个签名完全匹配委托的方法，但现在这个方法有两个参数（哪怕其中一个有默认值），编译器不会自动填充可选参数的默认值来适配委托的参数数量——方法组转换的规则就是要求方法签名（参数个数、类型）和委托严格匹配，不考虑可选参数的默认值特性。

3. Lambda表达式能正常运行的原因
   当你写f => Extensions.StringEnumerator.Parse<DocumentTypesEnum>(f)时，这不是方法组转换，而是显式的方法调用：你只传了一个参数f，编译器会自动帮你填充默认值ignoreCase = false，这完全符合方法调用时可选参数的使用规则，所以编译毫无问题。

补充John Skeet提到的观点 #

正如他所说，这本质上不是可选参数本身的问题，而是方法组转换不支持利用可选参数的默认值来适配委托。如果是命名参数的场景，方法组转换同样无法处理——编译器不会自动推断要使用命名参数来匹配委托，只有在直接调用方法时才会处理这些语法糖特性。

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