我注意到Resharper建议我转一下这个：
if (myObj.myProp is MyType)
{
...
}到这个：
var myObjRef = myObj.myProp as MyType;
if (myObjRef != null)
{
...
}为什么会建议这种变化？我习惯于Resharper提出优化更改和代码减少更改的建议，但这感觉就像是要接受我的单个语句并将其变成两条线。
根据MSDN：
一个是 表达式的计算结果为真，如果同时满足以下两个条件都满足：
表达式不为null。可以将表达式转换为type。也就是说，表单的强制转换表达式
(type)(expression)将完成而不会引发异常。
我is是否只是在一行中误读了该代码，或者不执行完全相同的检查，而无需为空检查显式创建另一个局部变量？
Answers:
因为只有一个演员。比较一下：
if (myObj.myProp is MyType) // cast #1
{
var myObjRef = (MyType)myObj.myProp; // needs to be cast a second time
// before using it as a MyType
...
}对此：
var myObjRef = myObj.myProp as MyType; // only one cast
if (myObjRef != null)
{
// myObjRef is already MyType and doesn't need to be cast again
...
}C＃7.0使用模式匹配支持更紧凑的语法：
if (myObj.myProp is MyType myObjRef)
{
...
}as可能要快几纳秒，但我认为这是过早的微优化。
myObj或的值myProp可能会在is和强制转换之间更改（通过另一个线程），从而导致不良行为。
as+ != null还将执行if定义的重写!=运算符MyType（即使myObjRef为null）。尽管在大多数情况下这不是问题（特别是如果您正确实现了它），但在某些极端情况下（错误的代码，性能），则可能不希望这样做。（虽然必须非常极端）
object.ReferenceEquals(null, myObjRef)。
最好的选择是使用模式匹配，例如：
if (value is MyType casted){
//Code with casted as MyType
//value is still the same
}
//Note: casted can be used outside (after) the 'if' scope, too目前尚无有关皮带下实际发生情况的信息。看一下这个例子：
object o = "test";
if (o is string)
{
var x = (string) o;
}这将转换为以下IL：
IL_0000: nop
IL_0001: ldstr "test"
IL_0006: stloc.0 // o
IL_0007: ldloc.0 // o
IL_0008: isinst System.String
IL_000D: ldnull
IL_000E: cgt.un
IL_0010: stloc.1
IL_0011: ldloc.1
IL_0012: brfalse.s IL_001D
IL_0014: nop
IL_0015: ldloc.0 // o
IL_0016: castclass System.String
IL_001B: stloc.2 // x
IL_001C: nop
IL_001D: ret 这里重要的是isinst和castclass通话-两者都相对昂贵。如果将其与替代方案进行比较，则可以看到它仅进行isinst检查：
object o = "test";
var oAsString = o as string;
if (oAsString != null)
{
}
IL_0000: nop
IL_0001: ldstr "test"
IL_0006: stloc.0 // o
IL_0007: ldloc.0 // o
IL_0008: isinst System.String
IL_000D: stloc.1 // oAsString
IL_000E: ldloc.1 // oAsString
IL_000F: ldnull
IL_0010: cgt.un
IL_0012: stloc.2
IL_0013: ldloc.2
IL_0014: brfalse.s IL_0018
IL_0016: nop
IL_0017: nop
IL_0018: ret 还值得一提的是，将使用值类型unbox.any而不是castclass：
object o = 5;
if (o is int)
{
var x = (int)o;
}
IL_0000: nop
IL_0001: ldc.i4.5
IL_0002: box System.Int32
IL_0007: stloc.0 // o
IL_0008: ldloc.0 // o
IL_0009: isinst System.Int32
IL_000E: ldnull
IL_000F: cgt.un
IL_0011: stloc.1
IL_0012: ldloc.1
IL_0013: brfalse.s IL_001E
IL_0015: nop
IL_0016: ldloc.0 // o
IL_0017: unbox.any System.Int32
IL_001C: stloc.2 // x
IL_001D: nop
IL_001E: ret 但是请注意，正如我们在此处看到的那样，这不一定意味着可以更快地得到结果。目前似乎已经改善，因为这个问题被问，但：铸件看起来就像他们曾经是，但要快速执行as和linq现在大约快3倍。
转载警告：
"Type check and direct cast can be replaced with try cast and check for null"
两者都可以工作，这取决于您的代码如何适合您。就我而言，我只是忽略了该警告：
//1st way is n+1 times of casting
if (x is A) ((A)x).Run();
else if (x is B) ((B)x).Run();
else if (x is C) ((C)x).Run();
else if (x is D) ((D)x).Run();
//...
else if (x is N) ((N)x).Run();
//...
else if (x is Z) ((Z)x).Run();
//2nd way is z times of casting
var a = x as Type A;
var b = x as Type B;
var c = x as Type C;
//..
var n = x as Type N;
//..
var z = x as Type Z;
if (a != null) a.Run();
elseif (b != null) b.Run();
elseif (c != null) c.Run();
...
elseif (n != null) n.Run();
...
elseif (x != null) x.Run();以我的代码第二种方式是更长和更差的性能。
IRunable。如果您没有控制权，也许可以使用dynamic？
它也应该建议第二个更改：
(MyType)myObj.myProp进入
myObjRef与原始代码相比，这节省了属性访问和强制类型转换。但只有更改is为后才有可能as。
(MyType)如果强制转换失败，将抛出异常。as只返回null。
is（该代码在问题中）。
我要说的是要制作myObj.myProp的强类型版本，即myObjRef。然后，当您在块中引用此值时，就必须使用它，而不必进行强制转换。
例如，这：
myObjRef.SomeProperty比这更好：
((MyType)myObj.myProp).SomeProperty
MyProp在进行此更改后就不需要使用吸气剂。