我最近正在使用一个DateTime对象，并写了这样的东西:
DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?
AddDays()的智能感知文档说它在日期后添加了一天，但它并没有这样做——它实际上返回了一个添加了一天的日期，所以你必须这样写:
DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date
这个问题以前已经困扰过我很多次了，所以我认为将最糟糕的c#陷阱分类会很有用。
当前回答
我一直认为值类型总是在堆栈上，引用类型总是在堆上。
但事实并非如此。当我最近在SO上看到这个问题时(可以说回答是错误的)，我才知道事实并非如此。
正如Jon Skeet的回答(引用Eric Lippert的博客文章)，这是一个神话。
相当重要的环节:
关于值类型的真相
引用不是aAddress
堆栈是实现细节第1部分
堆栈是实现细节第2部分
其他回答
可枚举对象可以计算不止一次
当您有一个惰性枚举的可枚举对象，并且对其进行两次迭代并得到不同的结果时，它会咬您一口。(或者你得到相同的结果，但它执行两次不必要的)
例如，在编写某个测试时，我需要一些临时文件来测试逻辑:
var files = Enumerable.Range(0, 5)
.Select(i => Path.GetTempFileName());
foreach (var file in files)
File.WriteAllText(file, "HELLO WORLD!");
/* ... many lines of codes later ... */
foreach (var file in files)
File.Delete(file);
想象一下当file . delete (file)抛出FileNotFound时我的惊讶!!
这里发生的情况是，可枚举的文件被迭代了两次(第一次迭代的结果根本没有被记住)，在每次新的迭代中，您将重新调用Path.GetTempFilename()，因此您将得到一组不同的临时文件名。
当然，解决方案是使用ToArray()或ToList()快速枚举值:
var files = Enumerable.Range(0, 5)
.Select(i => Path.GetTempFileName())
.ToArray();
当你在做一些多线程的事情时，这甚至更可怕，比如:
foreach (var file in files)
content = content + File.ReadAllText(file);
你会发现内容。在所有写入之后，长度仍然为0 !!然后，当....时，您开始严格检查是否没有竞态条件浪费了一个小时之后……你发现这只是一个微小的可枚举的东西，你忘记了....
LINQ to SQL和一对多关系
这是一个可爱的，咬了我几次，微软把它留给他们自己的开发人员放在她的博客。我不能说得比她更好，来看看。
LinqToSQL和空集聚合
看这个问题。
如果你有一个LinqToSql查询，你正在运行一个聚合——如果你的结果集是空的，Linq不能计算出数据类型是什么，即使它已经声明了。
例:假设你有一个带有Amount字段的Claim表，它在LinqToSql中是十进制类型。
var sum = Claims.Where(c => c.ID < 0).Sum(c => c.Amount);
显然，没有任何声明的ID小于零，因此应该看到sum = null，对吧?错了!您会得到一个InvalidOperationException，因为Linq查询底层的SQL查询没有数据类型。你必须明确地告诉Linq它是一个小数!因此:
var sum = Claims.Where(c => c.ID < 0).Sum(c => (decimal?)c.Amount);
这真的很愚蠢，在我看来，这是微软的设计错误。
明白了!
讨厌的Linq缓存抓到了你
看看我的问题导致了这个发现，以及发现这个问题的博主。
简而言之，DataContext保存了你曾经加载过的所有Linq-to-Sql对象的缓存。如果其他人对您之前加载的记录进行了任何更改，则您将无法获得最新数据，即使您显式地重新加载该记录!
这是因为DataContext上有一个名为ObjectTrackingEnabled的属性，默认为true。如果您将该属性设置为false，则记录将每次重新加载…但是…你不能使用SubmitChanges()持久化对该记录的任何更改。
明白了!
Dictionary<，>: "返回项的顺序未定义"。这很可怕，因为它有时会咬你一口，但会对其他人起作用，如果你只是盲目地认为Dictionary会表现得很好(“为什么不呢?”我想，是List做的”)，在你最终开始质疑你的假设之前，你真的必须深入了解它。
(这里也有类似问题。)
