默认参数是编译期特性，调用方需c# 4.0+且langversion≥4才能识别；跨项目调用时旧编译器会因无法解析默认值而报“无匹配重载”；接口中慎用，默认参数在.net framework 4.7.2及以下支持不全；可空类型默认值需用null或default(t?)以保留“未提供”语义；重载解析优先匹配最具体方法，加默认参数可能导致调用静默切换。
默认参数在 C# 中是编译期特性，不是运行时机制 —— 这意味着调用方必须用支持默认参数的 C# 版本（C# 4.0+）重新编译，否则传参逻辑不会自动补全，甚至可能因签名不匹配导致 MissingMethodException。
为什么加了默认参数却报错“没有重载与参数匹配”
常见于跨项目调用：A 项目用 C# 12 定义了带默认参数的方法，B 项目用 C# 3 编译器（或旧版 MSBuild）引用 A 的 DLL 并调用该方法，但未显式传参。此时编译器无法识别默认值，直接报错。
- 检查调用方项目的
LangVersion（在 .csproj 中），确保 ≥ 4，推荐显式设为<langversion>12</langversion> - 确认调用代码是否在编译时“看到”了默认值：把光标停在方法名上，IDE 应显示完整签名含
= null或= 0；若只显示void Foo(string s)，说明元数据未被正确解析 - 避免在接口中定义默认参数后，由 .NET Framework 项目实现 —— Framework 4.7.2 及以下对默认参数的接口实现支持不完整，容易触发绑定失败
string?、int? 和 string、int 的默认参数写法差异
可空类型和引用类型的默认值语义不同，写错会导致编译失败或行为异常。
-
string是引用类型，默认值只能是null或字符串字面量（如""），不能写default（除非显式转型：default(string)） -
string?与string在默认参数中等价，都允许null；但开启 nullable context 后，string默认不允许 null，需写= ""或= null!（不推荐后者） -
int?必须用= null或= default(int?)，不能写= 0（虽然 0 是有效值，但会丢失“未提供”的语义） - 错误示例：
void M(int? x = 0)—— 这会让调用M()和M(0)行为一致，无法区分“用户没传”和“用户传了 0”
默认参数 + 方法重载时的绑定优先级问题
C# 编译器在重载解析时，**先筛选所有可匹配的方法，再从中选最具体的那个**，默认参数不影响“是否可匹配”，只影响“是否需要显式传参”。
- 有
void Log(string msg)和void Log(string msg, LogLevel level = LogLevel.Info)，调用Log("hi")会绑定到单参数版本 —— 因为它更具体，哪怕双参数版有默认值 - 若删掉单参数版，
Log("hi")才会走双参数版并填充level - 陷阱：给重载方法加默认参数后，原有调用可能悄悄切换到另一个重载，引发逻辑偏差（比如日志级别被静默设为 Info 而非 Warning）
最易被忽略的是版本兼容性：即使你本地用 C# 12 写了默认参数，只要下游有一个项目用旧版 SDK 或未更新 LangVersion，它就看不到默认值，也编译不过。别依赖 IDE 显示正常就认为没问题 —— 看 CI 日志里实际用的 csc.exe 版本和参数。
