GameObject的==的一个坑和一点GameObject的内部构造
一切都是因为==，才有了这篇博客
测试
先放一段unity的一个普通的脚本
using UnityEngine;
public class UnityEngineObjectCheck : MonoBehaviour {
void Start () {
GameObject go1 = new GameObject ("go1");
GameObject go2 = new GameObject ("go2");
DestroyImmediate (go1);
Debug.Log ("go1 == null : " + (go1 == null).ToString());
Debug.Log ("go2 == null : " + (go2 == null).ToString());
GameObject go = go1 ?? go2;
Debug.Log ("go == null : " + (go == null).ToString());
}
}
这里有个 ?? 运算符有点意思我也是查了MSDN文档
其意思就是对null的判别 ，a??b意思就是a为空则返回b，a不为null则不会对b进行表达式计算，??=运算符在此基础上多加了把b赋给a的功能
结果和分析
先预测一波结果：
1、go被销毁了，那么第一个输出将是go1 == null : True；
2、没有对go2进行操作，那么第二个输出应该是go2 == null : False；
3、通过??运算符、go1既然是null、那么go将会被赋值为go2。因此第三个输出将是go == null : False。
然而实际运行结果：
这说明了go1并没有完全销毁，他不是null，C#的对象由GC(Garbage collector)来管理对象的生存，destroy针对的是UnityGameobject的对象，UnityGameObject继承了UnityEngine.Object类,而object类重载了==和!=运算符，所以GameObject的== 和!=就相应的被重载了 。
所以上面使用==使用unity内置的对象判null方式，如果你的底层对象被destory了那就为null没问题，而使用其他的运算符时，这个C#对象还活着，也就会出现上面的问题。
总结
综上所述加上我查的一些资料：
可以初步认为
GameObject= C#包裹对象 + UnityEngineC++底层对象
Destroy处理的是C++底层对象，销毁然后C#对象里面的指向底层对象指针指向一个null，就完成了destory这一步。
gameobj == null的来历就是如此了，写代码的时候注意不要踩坑就行。
文章大部分来自该博客：https://blog.csdn.net/serenahaven/article/details/83381501
