因此，明确地说，这是一种懒惰的编码风格。如果可以选择，我更喜欢原生类型;我将利用这一点额外的“噪音”来确保我在代码/调试时所编写和阅读的内容完全符合我的想法。耸肩*

如果编译器可以自动进行类型推断，那么就不会有任何性能问题。这两种方法都会生成相同的代码

var    x = new ClassA();
ClassA x = new ClassA();

然而，如果你是动态构造类型(LINQ…)，那么var是你唯一的问题，还有其他的机制来比较，以说明什么是惩罚。

因为还没有人提到反射器…

如果你编译以下c#代码:

static void Main(string[] args)
{
    var x = "hello";
    string y = "hello again!";
    Console.WriteLine(x);
    Console.WriteLine(y);
}

然后使用反射器对它，你得到:

// Methods
private static void Main(string[] args)
{
    string x = "hello";
    string y = "hello again!";
    Console.WriteLine(x);
    Console.WriteLine(y);
}

所以答案显然是没有运行时性能的影响!

因此，明确地说，这是一种懒惰的编码风格。如果可以选择，我更喜欢原生类型;我将利用这一点额外的“噪音”来确保我在代码/调试时所编写和阅读的内容完全符合我的想法。耸肩*

就像Joel说的，编译器在编译时计算出var应该是什么类型，实际上这只是编译器用来节省击键的一个技巧，举个例子

var s = "hi";

被替换为

string s = "hi";

在生成任何IL之前，编译器会调用。生成的IL将完全相同，如果你键入字符串。

我总是在网络文章或指南写作中使用var这个词。

网络文章的文本编辑器宽度较小。

如果我这样写:

SomeCoolNameSpace.SomeCoolClassName.SomeCoolSubClassName coolClass = new SomeCoolNameSpace.SomeCoolClassName.SomeCoolSubClassName();

你会看到上面渲染的预代码文本太长，流出框，它被隐藏。读者需要向右滚动才能看到完整的语法。

这就是为什么我总是在网络文章写作中使用关键字var。

var coolClass = new SomeCoolNameSpace.SomeCoolClassName.SomeCoolSubClassName();

整个渲染的预代码正好适合屏幕。

在实践中，对于声明对象，我很少使用var，我依靠智能感知来更快地声明对象。

例子:

SomeCoolNamespace.SomeCoolObject coolObject = new SomeCoolNamespace.SomeCoolObject();

但是，对于从方法返回对象，我使用var来更快地编写代码。

例子:

var coolObject = GetCoolObject(param1, param2);