C# 显式空检查与空合并运算符的编译器评估？

考虑下面的代码，它使用两种稍有不同的方法来检查

\u instance

，并在尚未设置时分配它

class InstantiationTest
{
    private Object _instance;

    public void Method1() {
        if(_instance == null) {
            _instance = new Object();
        }
    }

    public void Method2() {
        _instance = _instance ?? new Object();
    }
}

VS或Resharper会一直在我的显式空检查下划线，并提示我使用空合并操作符进行重构

我想知道编译器是否足够聪明，能够检测到

Method2（）

中的情况，其中

\u实例

被重新分配给自身（实际上是a？），并将

Method2（）

重写为

Method1（）

我看事实并非如此：

Test.Method1:
IL_0000:  ldarg.0     
IL_0001:  ldfld       UserQuery+Test._instance
IL_0006:  brtrue.s    IL_0013
IL_0008:  ldarg.0     
IL_0009:  newobj      System.Object..ctor
IL_000E:  stfld       UserQuery+Test._instance
IL_0013:  ret   

与：

Test.Method2:
IL_0000:  ldarg.0     
IL_0001:  ldarg.0     
IL_0002:  ldfld       UserQuery+Test._instance
IL_0007:  dup         
IL_0008:  brtrue.s    IL_0010
IL_000A:  pop         
IL_000B:  newobj      System.Object..ctor
IL_0010:  stfld       UserQuery+Test._instance
IL_0015:  ret      

我的问题是为什么

---

在编译器级别实现是很棘手的，太琐碎而不值得实现，还是我遗漏了什么

一般来说，C#编译器对IL的优化很少，这要由JIT来完成，JIT可以更好地优化特定体系结构。因此，它只是没有在编译器中实现，因为这会占用其他事情的时间。

这是有道理的，但您认为这是可以通过JIT优化的吗？可能。但是，如果您担心这样的差异对性能的影响，那就是“微优化”阵营中的问题，您应该去担心其他事情！