如何“欺骗”C#编译器允许合法场景下的未赋值变量使用？

我完全懂你的痛点——你的逻辑里bar在第一个if分支里肯定会被赋值（除非抛出异常），而且第二个if的foo.SomeFlag值和之前完全一致，理论上绝对不会出现bar未赋值就被使用的情况，但编译器就是认死理，非要报错。下面几种方法可以帮你“说服”甚至“欺骗”编译器放行：

1. 给变量加一个“肯定会被覆盖”的默认初始化（最稳妥） #

这不算严格意义上的“欺骗”，但能快速解决问题。你可以用null!或者default!告诉编译器：“我保证这个默认值永远不会被用到，你放心”。示例代码：

Bar bar = null!; // 适用于引用类型，null!禁用可空引用类型警告
// 或者对于值类型：Bar bar = default!;

if (foo.SomeFlag) {
    // ... 执行相关操作
    bar = ...; // 这里一定会覆盖默认值
}

// 执行其他操作

if (foo.SomeFlag) {
    // 放心使用bar，编译器不会再报错
}

注意：如果Bar是不可空值类型，default(Bar)会生成该类型的默认值（比如int的0），但只要你确保第一个if分支一定会赋值，就不会有问题。

2. 用Debug.Assert强化逻辑断言 #

在第二个if分支里先加一个断言，明确告诉编译器（和你自己）bar此时一定是已赋值状态。编译器有时候会根据这类断言推断变量的状态：

Bar bar;

if (foo.SomeFlag) {
    // ... 执行相关操作
    bar = ...;
}

// 执行其他操作

if (foo.SomeFlag) {
    Debug.Assert(bar != null, "bar必须已赋值，因为foo.SomeFlag为true");
    // 现在编译器会允许你使用bar了
}

这个方法的好处是既解决了编译错误，又能在调试阶段如果逻辑出问题时及时抛出警告，比直接用null!更安全。

3. 使用unsafe块绕过检查（真正的“欺骗”，不推荐） #

如果你铁了心要绕过编译器的静态检查，可以用unsafe代码直接操作变量的内存地址。但这种方法非常危险，一旦你的逻辑出现漏洞（比如foo.SomeFlag意外被修改），就会导致内存访问错误，所以只在你100%确定逻辑不会出错的情况下使用：

unsafe
{
    Bar bar;

    if (foo.SomeFlag) {
        // ... 执行相关操作
        bar = ...;
    }

    // 执行其他操作

    if (foo.SomeFlag) {
        Bar* barPtr = &bar;
        // 使用*barPtr来访问bar
    }
}

4. 重构逻辑（最优雅的根治方法） #

其实最好的解决方式是从逻辑上消除这个问题——既然两个if的条件完全一致，而且bar只在这个条件下被使用，你可以把bar的赋值和使用合并到同一个分支里：

if (foo.SomeFlag) {
    // ... 执行相关操作
    Bar bar = ...;
    // 先执行原本在两个if之间的“其他操作”（如果这些操作和bar无关）
    // 直接在这里使用bar
} else {
    // 执行原本在两个if之间的“其他操作”
}

这样代码逻辑更紧凑，编译器也不会有任何疑问，还能避免后续维护时可能出现的逻辑漏洞。

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