你最可能需要它的时候是匿名类型(100%需要);但它也避免了琐碎案件的重复，IMO使界限更加清晰。对于简单的初始化，我不需要看到类型两次。

例如:

Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

(请不要编辑上面的hscroll -它有点证明了这一点!!)

vs:

var data = new Dictionary<string, List<SomeComplexType<int>>>();

然而，在某些情况下，这是一种误导，并可能导致错误。如果原始变量和初始化类型不相同，请谨慎使用var。例如:

static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}

// this working code...
IFoo oldCode = new Foo();
DoSomething(oldCode);
// ...is **very** different to this code
var newCode = new Foo();
DoSomething(newCode);

I don't understand why people start debates like this. It really serves no purpose than to start flame wars at then end of which nothing is gained. Now if the C# team was trying to phase out one style in favor of the other, I can see the reason to argue over the merits of each style. But since both are going to remain in the language, why not use the one you prefer and let everybody do the same. It's like the use of everybody's favorite ternary operator: some like it and some don't. At the end of the day, it makes no difference to the compiler.

这就像和你的兄弟姐妹争论你最喜欢的父母是谁:除非他们离婚了，否则没关系!

来自Essential LINQ:

除非绝对必要，否则最好不要显式声明范围变量的类型。例如，下面的代码编译干净，但是编译器可以在没有正式声明的情况下推断出类型:

List<string> list = new List<string> { "LINQ", "query", "adventure" };
var query = from string word in list
      where word.Contains("r")
      orderby word ascending
      select word;

显式声明range变量的类型会强制对LINQ Cast操作符进行幕后调用。此调用可能会产生意想不到的结果，并可能会损害性能。如果您在LINQ查询中遇到性能问题，像这里所示的强制转换可能是开始寻找罪魁祸首的一个地方。(此规则的一个例外是当您使用非泛型Enumerable时，在这种情况下您应该使用强制转换。)

我只在清楚地看到使用的类型时使用var。

例如，在这种情况下，我会使用var，因为你可以立即看到x将是“MyClass”类型:

var x = new MyClass();

我不会在这种情况下使用var，因为你必须将鼠标拖动到代码上，并查看工具提示来查看MyFunction返回的类型:

var x = MyClass.MyFunction();

特别是，在右边甚至不是一个方法，而只是一个值的情况下，我从不使用var:

var x = 5;

(因为编译器不知道我想要一个字节，短，int或其他)

Apart from readability concerns, there is one real issue with the use of 'var'. When used to define variables that are assigned to later in the code it can lead to broken code if the type of the expression used to initialize the variable changes to a narrower type. Normally it would be safe to refactor a method to return a narrower type than it did before: e.g. to replace a return type of 'Object' with some class 'Foo'. But if there is a variable whose type is inferred based on the method, then changing the return type will mean that this variable can longer be assigned a non-Foo object:

var x = getFoo(); // Originally declared to return Object
x = getNonFoo();

所以在这个例子中，改变getFoo的返回类型会使getNonFoo的赋值变为非法。

如果getFoo和它的所有用途都在同一个项目中，这不是什么大问题，但如果getFoo在一个库中供外部项目使用，如果他们像这样使用'var'，你就不能确保缩小返回类型不会破坏某些用户的代码。

正是由于这个原因，当我们在Curl编程语言中添加类似的类型推断特性(在Curl中称为'def')时，我们阻止了对使用这种语法定义的变量的赋值。

在IEnumerable<int>和IEnumerable<double>之间的比较中，你不需要担心-如果你传递了错误的类型，你的代码无论如何都不会编译。

不需要考虑类型安全，因为var不是动态的。这只是编译器的魔法，任何类型不安全的调用都会被捕获。

Linq绝对需要Var:

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new { 
        PostName = post.Name, 
        post.Date, 
        AuthorName = author.Name
    };

现在看看智能感知中的anonEnumeration，它会显示类似IEnumerable<'a>

foreach( var item in anonEnumeration ) 
{
    //VS knows the type
    item.PostName; //you'll get intellisense here

    //you still have type safety
    item.ItemId;   //will throw a compiler exception
}

c#编译器非常聪明——单独生成的anon类型如果它们的属性匹配，将具有相同的生成类型。

除此之外，只要你有智能感知，在上下文清楚的地方使用var是有意义的。

//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();

//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();

//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;