c# 8引入了新特性：“可為空參考”（詳情），這個功能個人覺得挺好的，能夠非常明確的表現程式設計者的意圖，編譯器能夠進行檢查，盡最大可能減小NullReferenceException錯誤，

如果是新專案，那么上手很簡單，一點點搭建起來，遇山開山，遇河渡河，但是對于我這種手頭上的專案大多都是以前創建的情況，就要稍微做那邊么一點操作了，

要看完整說明，請查看開頭的那個鏈接，

準備

首先評估一下幾個條件：

專案可以基于.NET CORE 3.0及以上編譯，如果不行，那么就請直接右上角點×，
是不是大多數的變數都需要null參考？如果是的話，個人覺得不值得費勁了，

操作

以一個ASP.NET WEBAPI為例，專案修改前是能夠正常編譯無錯誤無警告的，

1. 啟用Nullable（可為空參考型別）

Nullable默認是不啟用的，需要做一些修改以啟用，有兩種方式：

修改csproj檔案，在ProperyGroup里面添加enable項，

對于比較小型的專案，可以直接修改，這樣彈出來的警告或者錯誤會比較少，方便我們快速改正，

使用編譯器指令#nullable enable和#nullable restore進行修改，在代碼段的開頭enable，結尾處restore，

對于中大型專案，直接使用第一種方式進行修改會導致大量的警告，很容易一團糟；可以通過編譯器指令對單檔案或者單類進行修改操作，一點一點地修改，

2. 修改代碼

我的專案使用第一種方法的的情況下有24個警告（編譯后有67個），也不知道算多還是算少，

物體類

[DataContract]
    [Table("recordinfo")]
    public class RecordInfo : InfoBase
    {
        /// <summary>
        /// 記錄ID
        /// </summary>
        [DataMember]
        [Key]
        public string RecordNum { get; set; }
        /// <summary>
        /// 車輛RFID號碼
        /// </summary>
        [DataMember]
        public string CarID { get; set; }

RecordNum為主鍵，通過EF進行映射，結果也不會為null，所以宣告應該保持原樣即可，CarID不是主鍵，有可能是null，因此應當顯式宣告為string?，表示可以為空，洗掉警告，

編譯器檢查，RecordNum沒有被初始化，我們的設計意圖告訴編譯器了，但是代碼還沒有保證這個不能為空，因此需要修改代碼保證RecordNum不為空，

這里使用null包容運算子（！）來進行操作，提示編譯器這個位置實際上不會為null，

//string的default為null，通過增加！告訴編譯器，這塊初始化的時候實際上是不為空的，
public string RecordNum { get; set; } = default!;

null包容運算子并不能確保不是null，如果可以使用代碼確保不為null，那么使用代碼會是更優選擇，考慮如下代碼：

//我經常使用String.IsNullOrWhiteSpace來進行檢查，空文本對我的業務沒有意義，因此適用，
public string RecordNum { get; set; } = "";

特別提示：
可為空參考型別檢查是編譯器的行為，它可以提供編譯時檢查，但是不提供運行時檢查，如果使用外部代碼呼叫，那么是否為空都可以進行賦值，

很明顯，上面代碼運行時也很難保證不是null，我們可以再改進一下，

public string RecordNum
{
    get => recordNum;
    set => recordNum = value ?? "";
}
private string recordNum = "";

官方推薦對POCO類使用建構式保證不為空，
指定了default!的情況，ASP.NET CORE WEBAPI會內部自動標注[Required]，遠程呼叫如果缺失引數，會提示bad request，

DataContext類

DataContext也是類似的，主要是DbSet物件的參考問題，

來自.NET Class Library

//BaseDirectory的回傳是string?型別的
var baseDirectory = System.AppDomain.CurrentDomain.BaseDirectory;
//Path.Combine()不接受string?，提示錯誤，
var xmlPath = Path.Combine(baseDirectory, System.AppDomain.CurrentDomain.FriendlyName + ".xml");

這是一個潛在的bug點，對于以上代碼，很顯然BaseDirectory的回傳為null不符合我們的設計，我們可以進行如下改造，

var baseDirectory = System.AppDomain.CurrentDomain.BaseDirectory;
if (baseDirectory == null) throw new ArgumentNullException("baseDirectory");
var xmlPath = Path.Combine(baseDirectory, System.AppDomain.CurrentDomain.FriendlyName + ".xml");

泛型類

public class ReturnData<T>
{
    //整個型別會提示Data未能初始化，ErrorMsg未能初始化，
    public ReturnData(){ }
    public ReturnData(T data) => Data = https://www.cnblogs.com/podolski/p/data;
    public ReturnData(string error) => ErrorMsg = error;
    /// 
    /// 頁面資料
    /// 
    public T Data { get; set; }
    public string ErrorMsg { get; set; }
}

設計意圖：Data與ErrorMsg不同時為空，也不同時有值，

基于設計，可以做如下修改，注意添加了class約束，

public class ReturnData<T>
    where T: class
{
    public ReturnData(){ }
    public ReturnData(T data) => Data = https://www.cnblogs.com/podolski/p/data;
    public ReturnData(string error) => ErrorMsg = error;
    /// 
    /// 頁面資料
    /// 
    public T? Data { get; set; }
    public string? ErrorMsg { get; set; }
}

其他例子

using ManageDataContext context = new ManageDataContext();
var props = contextType.GetProperty($"{namestring}s");
//props提示有可能為null
var dbset = (props.GetValue(context) as DbSet<T>);
//提示dbset可能為null
var res = await dbset.FindAsync(value);

可以調整為下面的形式：

using ManageDataContext context = new ManageDataContext();
var props = contextType.GetProperty($"{namestring}s");
//判斷props可以解決問題，
if (props == null) throw new ArgumentNullException("Props");
var dbset = (props.GetValue(context) as DbSet<T>);
//判斷dbset可以解決問題，
if (dbset == null) throw new ArgumentNullException("dbset");
var res = await dbset.FindAsync(value);

注意，將as替換為強制轉換，并不能消除警告，