启用Nullable类型后Razor Pages的ModelState为何无效？

问题背景 #

为学习目的复制改写了ASP.NET Core官方Cookie认证示例代码，耗时很久才发现示例所有using语句前都加了#nullable disable。

遇到的具体问题 #

我的代码启用了可空引用类型，当Post方法签名包含returnUrl参数时：

public async Task<IActionResult> OnPostAsync(string returnUrl = null)
{
    if (ModelState.IsValid)
    {
        // ... 业务逻辑
    }
}

ModelState始终无效。原本以为启用可空引用类型不会破坏向后兼容性、不会改变代码运行逻辑，但框架的处理却因为可空开关的状态，改变了ModelState.IsValid的结果，完全超出预期。

附注：当前实现其实不需要这个参数，推测使用这类来自查询的参数时，要么确保不生成null，要么让action handler接受null，实现会更稳定？

疑问 #

• 在Razor Pages/ASP.NET Core/Blazor框架中，还有哪些场景会因可空引用类型的启用/禁用而表现不同？
• 相关最佳实践是什么？是否要像官方示例一样为Razor Pages禁用可空引用类型？

关于Razor Pages可空引用类型的批评 #

Andrew Lock在文章中提出了以下核心问题：

• Razor Pages的模型绑定系统与可空引用类型适配不佳：当参数为非可空引用类型但未提供值时，模型绑定会直接抛出异常，而非传统方式仅将错误添加到ModelState
• 页面模型属性初始化冗余：启用可空后，未初始化的引用类型属性会产生大量编译警告，开发者被迫添加冗余的null检查或初始化代码，降低开发效率
• 框架API适配不全：部分框架自身的API设计未完全适配可空引用类型，导致开发者使用时需额外处理可空性冲突

解答 #

为什么ModelState无效？ #

启用可空引用类型时，string returnUrl = null的签名会被编译器视为非可空字符串类型但默认值为null，模型绑定系统会判定该参数为必填项。如果请求中未提供returnUrl的值，模型绑定会自动为ModelState添加验证错误，导致ModelState.IsValid为false。而禁用可空时，框架不会触发这项验证，因此ModelState不受影响。

其他受可空开关影响的场景 #

• 模型绑定：非可空引用类型的参数/属性若未绑定到有效值，启用可空时会触发验证错误或抛出异常（取决于配置）；禁用可空时仅会在ModelState中添加错误（不会抛出）
• 页面模型属性初始化：启用可空后，未初始化的引用类型属性会产生编译警告，开发者必须显式初始化或标记为可空
• Blazor组件参数：非可空组件参数若未提供值，启用可空时会在运行时抛出异常；禁用可空时则允许null传入
• 依赖注入：若注入的服务类型为非可空引用类型但容器中未注册，启用可空时会在构建服务提供器时抛出异常；禁用可空时可能返回null（取决于DI配置）

最佳实践 #

1. 按需启用可空：新项目建议全局启用可空引用类型，但针对Razor Pages页面模型单独调整：
   • 在页面模型文件顶部添加#nullable disable规避模型绑定和属性初始化问题
   • 或在项目文件中配置<Nullable>enable</Nullable>，同时对页面模型的非必填参数显式标记为可空（如string? returnUrl = null）
2. 明确参数可空性：对于来自请求的参数，必填项用非可空类型，可选项用可空类型（string?），避免出现默认值为null的非可空参数
3. 优化编译警告：对页面模型中必须为null的属性，使用[AllowNull]或[NotNull]属性修正可空警告，减少冗余代码
4. 跟进框架升级：ASP.NET Core 7.0及后续版本对可空引用类型的适配已逐步优化，升级框架可减少此类问题

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