启用可空引用类型上下文时如何重构C#构造函数链？

你提到的单全参构造+所有参数可空默认null的写法虽然能消掉警告，但会直接削弱可空引用类型的检查能力——原本必填的参数会被错误标记为可空，调用方传null时编译器不会告警，反而违背了你开启NRT防NullReferenceException的初衷。
下面是按推荐优先级排序的更优方案： #

方案1：最小改动，精准标注可选参数的可空性（最推荐） #

核心逻辑很简单：哪个参数允许为null，就只给哪个参数加?可空标记，必填参数始终保持非空声明，同时给全参构造的可选参数设置默认值，完全保留原有构造函数链的语义，老调用方代码不需要任何修改。
修改后的代码如下：

public class Foo
{   
    // 主构造函数：明确区分必填非空参数、可选可空参数
    public Foo(string first, string? second = null, string? third = null)
    {
        // 可选：加null校验兜底，避免通过反射等绕过编译器检查的场景传null
        this.First = first ?? throw new ArgumentNullException(nameof(first));
        this.Second = second;
        this.Third = third;
    }

    // 保留原有重载，完全兼容旧代码调用逻辑，不会触发编译警告
    public Foo(string first, string second) : this(first, second, null)
    {
    }

    public Foo(string first) : this(first)
    {
    }

    // 属性对应标注可空性：First必填非空，Second、Third允许为null
    public string First { get; set; }
    public string? Second { get; set; }
    public string? Third { get; set; }
}

这个方案的优势：

• 零破坏性变更：所有旧代码的构造调用方式完全不用改
• 保留NRT的检查能力：调用方如果给first传null，编译器会直接告警，不会漏过潜在空引用
• 改动量极小，只需要给原本就允许为null的参数、属性加上?标记即可

方案2：参数不允许为null的场景，用null原谅运算符配合校验兜底 #

如果你的业务逻辑要求Second、Third其实是非必填但不允许为null，旧代码传null只是历史遗留的临时缺省逻辑（比如后续会在构造函数内给这些参数赋默认值），可以用null!（null原谅运算符）告诉编译器跳过此处的null检查，同时在主构造函数里补全对应的赋值/校验逻辑，避免运行时空引用。
示例代码：

public class Foo
{   
    public Foo(string first, string second, string third)
    {
        this.First = first ?? throw new ArgumentNullException(nameof(first));
        // 给缺省的second、third赋业务默认值，保证属性始终非空
        this.Second = second ?? "默认Second值";
        this.Third = third ?? "默认Third值";
    }

    public Foo(string first, string second) : this(first, second, null!)
    {
    }

    public Foo(string first) : this(first, null!)
    {
    }

    // 三个属性都是非空，不需要加?标记
    public string First { get; set; }
    public string Second { get; set; }
    public string Third { get; set; }
}

注意：null!仅在编译阶段生效，不会做任何运行时转换，绝对不要在没有兜底赋值/校验的场景滥用，否则运行时还是会抛出空引用异常。

为什么不推荐全参数标记为可空的方案 #

这种写法相当于主动放弃了可空引用类型的校验能力：

• 原本必填的first参数被标记为可空后，调用方传入null编译器不会给出任何警告，完全违背了开启NRT的初衷
• 所有参数都带null默认值后，调用方可以写出new Foo(null, null, null)这类完全不符合业务要求的代码，反而引入更多潜在空风险

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