除了明显的用途之外var对于 LINQ，我还用它来缩写繁琐的变量声明以提高可读性，例如：
var d = new Dictionary<string, Dictionary<string, Queue<SomeClass>>>();
总的来说，我从静态类型中得到了一种安慰（因为想要一个更好的词），这让我不愿意放弃它。我喜欢在声明变量时知道自己在做什么的感觉。声明变量不仅仅是告诉编译器一些事情，它还告诉阅读代码的人一些事情。
让我举一个例子。假设我有一个方法返回一个List<string>。这段代码当然是正确的，我认为 90% 的 C# 开发人员可能会这样编写它：
List<string> list = MyMethod();
显然，对吧？事实上，这是一个您可以轻松使用的地方var.
确实如此。但this代码的版本不仅仅是声明一个变量，它告诉我编写它的人打算做什么：
IEnumerable<string> list = MyMethod();
编写该代码的开发人员告诉我“我不会更改此列表，也不会使用索引来访问其成员。我要做的就是迭代它。”在一行代码中可以传达大量信息。如果你使用它，你就会放弃它var.
当然，如果您一开始就没有使用它，您就不会放弃它。如果您是那种会编写该行代码的开发人员，那么您已经知道您不会使用var there.
Edit:
我刚刚重读了乔恩·斯基特（Jon Skeet）的帖子，埃里克·利珀特（Eric Lippert）的这句话突然引起了我的注意：
隐式类型的局部变量只是一种小方法，您可以通过它来淡化“方式”，从而强调“内容”。
我认为实际上在很多情况下使用隐式类型会留下隐式内容。不要纠结于“什么”就可以了。例如，我会随意编写一个 LINQ 查询，如下所示：
var rows = from DataRow r in parentRow.GetChildRows(myRelation)
where r.Field<bool>("Flag")
orderby r.Field<int>("SortKey")
select r;
当我阅读该代码时，我想到的一件事是“rows is an IEnumerable<DataRow>。”因为我知道 LINQ 查询返回的是IEnumerable<T>，我可以在那里看到正在选择的对象的类型。
这是一个什么情况hasn't已明确。这就留给我去推断了。
现在，在我使用 LINQ 的大约 90% 的情况下，这一点并不重要。因为 90% 的情况下，下一行代码是：
foreach (DataRow r in rows)
但不难想象在其中声明非常有用的代码rows as IEnumerable<DataRow>- 正在查询许多不同类型的对象的代码，将查询声明放在迭代旁边是不可行的，并且能够检查会很有用rows与智能感知。这是一个“是什么”的问题，而不是一个“如何”的问题。
