.NET Core 6自定义IdentityUser类中为何建议使用string?而非string属性

嘿Jaime，这问题其实是.NET 6默认开启的**可空引用类型（Nullable Reference Types）**特性在起作用，我给你一步步讲明白：

1. 为啥string本来能为null，却建议用string? #

在你熟悉的.NET Framework里，默认是没开启可空引用类型特性的，string作为引用类型确实天生能存null，编译器也不会管你有没有可能把它设为null。

但到了.NET 6，这个特性默认是开启的。开启后，编译器会把不带?的引用类型（比如string）默认当成非可空的——意思是它认为你声明的public string FirstName { get; set; }永远不应该是null，如果你不小心给它赋值null，或者在没判断null的情况下直接用，编译器就会抛出警告提醒你。

而string?就是明确告诉编译器：“我知道这个字符串可以是null，你不用提醒我啦”，同时也能让其他看代码的开发者一眼就明白这个属性允许空值，属于代码可读性和编译时校验的双重优化。

2. 为啥Nullable<string>报错，string?却正常 #

这是因为Nullable<T>这个泛型结构体是专门为值类型设计的——比如int、bool这些本身不能为null的值类型，用Nullable<int>（或者简写int?）来让它们支持存储null。

而string是引用类型，本来就支持null，所以Nullable<string>违反了Nullable<T>的泛型约束（T必须是值类型），编译器自然会报错。

至于string?，它是C#为可空引用类型专门设计的语法标记，和值类型的int?本质不一样——它不会改变string作为引用类型的本质，只是给编译器传递一个“这个变量允许为null”的信号，所以编译器不仅不会报错，还会根据这个标记调整空检查的逻辑。

如果实在不习惯这个特性，你可以在项目的.csproj文件里把<Nullable>enable</Nullable>改成<Nullable>disable</Nullable>，就能回到.NET Framework时代的行为，但还是建议保留开启，毕竟能提前帮你规避很多运行时的空引用异常～

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