Your understanding is true. That sounds like trying to micro-optimize to me. You should use a normal cast when you are sure of the type. Besides generating a more sensible exception, it also fails fast. If you're wrong about your assumption about the type, your program will fail immediately and you'll be able to see the cause of failure immediately rather than waiting for a NullReferenceException or ArgumentNullException or even a logical error sometime in the future. In general, an as expression that's not followed by a null check somewhere is a code smell.

另一方面，如果您对强制转换不确定，并期望它失败，则应该使用as，而不是用try-catch块包装的普通强制转换。此外，建议在类型检查和强制转换之后使用as。而不是:

if (x is SomeType)
   ((SomeType)x).SomeMethod();

它为is关键字生成isinst指令，为强制转换生成castclass指令(有效地执行两次强制转换)，你应该使用:

var v = x as SomeType;
if (v != null)
    v.SomeMethod();

这只会生成一条isinst指令。前一种方法在多线程应用程序中有一个潜在的缺陷，因为竞态条件可能会导致变量在is检查成功后改变其类型，并在转换行处失败。后一种方法不容易出现这种错误。

不建议在生产代码中使用以下解决方案。如果你真的讨厌c#中的这种基本构造，你可以考虑切换到VB或其他语言。

如果一个人非常讨厌强制转换语法，他/她可以写一个扩展方法来模仿强制转换:

public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
    return (T)o;
}

使用整齐的[?语法:

obj.To<SomeType>().SomeMethod()

直接强制转换比as关键字更需要一对括号。所以即使在你100%确定是什么类型的情况下，它也减少了视觉上的混乱。

不过我同意例外的情况。但至少对我来说，大多数as的使用都是在之后检查null，我发现这比捕获异常更好。

人们如此喜欢as，因为它让他们觉得没有例外……就像盒子上的担保。一个男人在盒子上放了一个华丽的保证，因为他想让你觉得里面温暖舒适。你觉得晚上把那个小盒子放在枕头下面，担保仙女可能会下来留下25美分，对吗，泰德?

回到正题…使用直接强制转换时，可能会出现无效的强制转换异常。因此，人们将as作为一个全面的解决方案应用于他们所有的强制转换需求，因为as(本身)永远不会抛出异常。但有趣的是，在你给出的例子中(x作为T).SomeMethod();您正在用无效的强制转换异常换取空引用异常。当您看到异常时，会混淆真正的问题。

我一般不会用太多。我更喜欢is测试，因为对我来说，它看起来更可读，比尝试强制转换和检查null更有意义。

我在这里写了一点:

http://blogs.msdn.com/ericlippert/archive/2009/10/08/what-s-the-difference-between-as-and-cast-operators.aspx

我明白你的意思。我同意它的重点:强制转换操作符传达的是“我确信这个对象可以转换为那种类型，如果我错了，我愿意冒一个异常的风险”，而“as”操作符传达的是“我不确定这个对象可以转换为那种类型;如果我错了，就给我一个null。”

然而，有一个微妙的区别。whatever()表示“我知道x不仅可以转换为T，而且这样做只涉及引用或开箱转换，而且x不是空的”。这确实传达了不同于(T)x). whatever()的信息，也许这就是代码作者的意图。

这是我最讨厌的事之一。

Stroustrup的D&E和/或一些我现在找不到的博客文章讨论了to操作符的概念，它将解决https://stackoverflow.com/users/73070/johannes-rossel提出的观点(即，与as相同的语法，但使用DirectCast语义)。

这个没有被实现的原因是因为施法应该会造成疼痛和丑陋，所以你会被推远使用它。

遗憾的是，“聪明的”程序员(通常是书籍作者(Juval Lowy IIRC))以这种方式滥用as来绕过这一点(c++没有提供as，可能是出于这个原因)。

甚至VB也有统一的语法，迫使你选择TryCast或DirectCast，并做出决定!

我经常看到这篇误导性文章的引用，作为“as”比cast更快的证据。

本文中比较明显的误导之一是图表，它没有指出要度量的是什么:我怀疑它度量的是失败的强制转换(其中“as”显然要快得多，因为没有抛出异常)。

如果您花时间进行测量，那么您将看到，当强制转换成功时，强制转换比“as”更快。

我怀疑这可能是“货物崇拜”使用as关键字而不是演员的原因之一。