使用var实际上是慢吗？ 如果是这样，为什么？
我正在学习C＃和.NET，我经常在我的代码中使用关键字var 。 我从Eric Lippert那里得到了这个想法，我喜欢它如何提高代码的可维护性。
我很想知道，虽然…已经在博客中写了很多关于缓慢堆位的引用，但我自己并没有观察到这一点。 这实际上很慢吗？ 我指的是由于类型推断导致编译时间慢。
你说：
由于类型’推理’，我指的是编译速度慢
这不会减慢编译器的速度。 编译器必须知道表达式的结果类型，以便检查赋值的兼容性（直接或间接）。 在某些方面，使用这种已知类型会删除一些内容（例如，可能需要检查inheritance，接口和转换运算符）。
它也不会减慢运行时间; 它们是完全静态编译的，就像常规的c＃变量（它们是）。
简而言之…… 事实并非如此 。
C＃中的’var’不是你在VB中习惯的VARIANT。 var是简单的语法糖，编译器允许您使用它来缩写类型。 编译器会计算表达式右侧的类型，并将变量设置为该类型。 它根本没有性能影响 – 就像你输入完整类型表达式一样：
var x = new X();
完全一样的
X x = new X();
这似乎是一个微不足道的例子，而且确实如此。 当表达式更加复杂甚至“无法表达”（如匿名类型）和枚举时，这真的很闪耀。
在编译时将Var替换为您的实际变量类型。 你在想dynamic吗？
“变体”是无类型的，因此访问状态（或内部状态转换）总是必须经历两个步骤：（1）确定“真实”内部类型，以及（2）从“真实”内部类型中提取相关状态。
当您使用类型化对象开始时，您没有这两步过程。
确实，“变体”因此具有这种额外的开销。 适当的用途是在那些你希望任何类型的方便性来简化代码的情况下，就像大多数脚本语言或非常高级的API一样。 在这些情况下，“变体”开销通常不重要（因为您无论如何都在使用高级API）。
如果你在谈论“ var ”，那么这只是一种方便的方式，你可以说，“编译器，在这里放置正确的类型”，因为你不想做那项工作，编译器应该能够弄明白。 在这种情况下，“ var ”不代表（运行时）“变体”，而仅仅是源代码规范语法。
编译器从构造函数中推断出类型。
var myString = "123"; 与string myString = "123";没什么区别string myString = "123";
此外，一般来说，引用类型存在于堆上，值类型存在于堆栈中，无论它们是否使用var声明。