很多小伙伴在升级到Visual Studio 2022后发现，如果我们去新建一个.NET 6的项目，和原先VS2019中一摸一样的写法，却会出现CS8618 Non-nullable property或者其他可能为null的警告。虽然不影响代码的编译和运行，却让人心里不踏实。
这是因为VS2019除了.NET Core 3.x的项目类型，都是默认使用C# 7.3版本。而从C# 8.0之后，增加了对可为null类型的检查，旨在最大程度的减少运行时出现NullReference异常。
除非小伙伴们时刻关心C#版本更新内容，否则这个随着VS2022和.NET 6默认开启的新特性，可能带来的不是惊喜，反而有一点惊吓。
那么让我们来看看如何迎接这个新的改变。这个变化的主旨是希望代码中，尽可能不再有为null的情况。首先我们来看最常见的一个Warning，在属性声明的时候。
平平无奇的写法，其中却蕴藏着两个Warnings。这种的处理较为简单，给出明确的初始值即可。例如string.Empty。你可以觉得这是在脱裤子放屁，但是回过头想一想，在运行过程中FristName和LastName为“”的情况，一定是代码有意为之。而不是不知道哪里返回了一个null，且无意中赋值上去了。
第二种常见的情况，是我们获得了一个可为null类型的对象，然后直接使用了。下图中XDocument的Load方法返回了Xelement?类型的对象。如果我们不做null check，就会存在Warning的波浪线。
一般来说这里加个if判断，就完事了。至少这个方法本身算是交差了。就像Xdocument.Root这个属性一样。但是业务代码的设计，和基础框架API的设计在思路上是有区别的。业务代码在业务明确的情况下返回null，会造成一种无限套娃的微妙效果。就像下面这个，到了外面一层的使用方法，仍然要纠结于null check。
从这个方法看，如果我就是一定要获取Root对象，或者对Root对象做一些不可描述的事情。那么XML文件中root节点为空就是一个不可接受，完全错误的情况。我个人倾向直接throw NullReferenceException。
另一种相似的情况是，可空类型被作为参数在接下来的代码中使用。下面代码中的attribute在业务逻辑中，很有可能就不应该存在为null的情况。否则就是输入的源头有错误。
这时要么通过if来回避参数为null这个错误，要么干脆就把错误暴露出来。这里推荐使用ArgumentNullException的静态方法ThrowIfNull。比先写个if判断再throw的方式要省力得多。
Visual Studio通过代码静态分析来判断是否报告可为null的Warning。但是代码写起来是非常灵活的，所以有时候会有误报或者分析不出来的情况。比如下面这个例子。
明明已经对相同的对象做了null check，但仍然会有Warning，这是因为Visual Studio并不认为这两段重复的代码是同一个东西。处理的方式也很简单，一是老老实实通过建立局部变量的引用来避免重复。
二是通过惊叹号（!）操作符告诉Visual Studio，我确信这里没有问题，别逼逼了。所以可以有下面这个写法。当然我个人并不推荐这么做，首先是这个写法不兼容之前低版本的C#，万一要做一个向低版本的移植或兼容就麻烦了。其次!操作符有些过度自信的感觉，它没有实际的意义，仅仅是关闭了这个Warning，颇有掩耳盗铃的意思。
以上就是今天想和大家讨论的，关于迁移到Visual Studio 2022和C# 10以后，遇到的可为null类型的问题。持续性的学习不是说要每个小版本都紧跟潮流，而是在每一次的新项目，新团队，新机遇到来的时候，即时地更新自己。一点浅见，抛砖引玉。
以下链接，是MS Learn上Windows开发的入门课程，单个课程三十分钟到60分钟不等，想要补充基础知识的同学点这里：
开始使用 Visual Studio 开发 Windows 10 应用