很多小夥伴在升級到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 應用