OP引用的消息来源有一定的可信度。。。但微软呢？对结构使用的立场是什么？我向微软寻求了一些额外的学习，以下是我的发现：

如果类型很小，通常寿命很短，或者通常嵌入其他对象。除非类型具有以下所有特征，否则不要定义结构：它在逻辑上表示单个值，类似于基本类型（整数、双精度等）。它的实例大小小于16字节。它是不可变的。它不必经常装箱。

Microsoft一贯违反这些规则

好吧，无论如何，第二和第三。我们喜爱的字典有两个内部结构：

[StructLayout(LayoutKind.Sequential)]  // default for structs
private struct Entry  //<Tkey, TValue>
{
    //  View code at *Reference Source
}

[Serializable, StructLayout(LayoutKind.Sequential)]
public struct Enumerator : 
    IEnumerator<KeyValuePair<TKey, TValue>>, IDisposable, 
    IDictionaryEnumerator, IEnumerator
{
    //  View code at *Reference Source
}

*参考源

“JonnyCantCode.com”的消息源得到了4分之3的结果，这是可以原谅的，因为第4名可能不会成为问题。如果您发现自己正在装箱一个结构，请重新思考您的体系结构。

让我们来看看为什么微软会使用这些结构：

每个结构Entry和Enumerator表示单个值。速度条目永远不会作为Dictionary类之外的参数传递。进一步的调查表明，为了满足IEnumerable的实现，Dictionary使用了每次请求枚举器时都会复制的枚举器结构。。。有道理。Dictionary类的内部。枚举器是公共的，因为Dictionary是可枚举的，并且必须对IEnumerator接口实现（例如IEnumeratorgetter）具有同等的可访问性。

更新-此外，请注意，当一个结构实现了一个接口（如Enumerator）并被强制转换为该实现的类型时，该结构将成为一个引用类型并被移动到堆中。在Dictionary类内部，Enumerator仍然是值类型。然而，一旦方法调用GetEnumerator（），就会返回一个引用类型IEnumerator。

我们在这里没有看到任何保持结构不可变或保持实例大小仅为16字节或更少的尝试或证明：

上面的结构中没有任何内容声明为只读-不是不可变的这些结构的大小可能远远超过16字节条目具有未确定的生存期（从Add（）到Remove（）、Clear（）或垃圾收集）；

和4.两个结构都存储TKey和TValue，我们都知道它们非常适合作为引用类型（添加了额外的信息）

尽管有哈希键，但字典速度很快，部分原因是实例化结构比引用类型更快。这里，我有一个Dictionary＜int，int＞，它存储了300000个随机整数和顺序递增的键。

容量：312874内存大小：2660827字节完成调整大小：5ms填充总时间：889ms

容量：必须调整内部数组大小之前可用的元素数。

MemSize：通过将字典序列化为MemoryStream并获得字节长度（对于我们的目的来说足够精确）来确定。

完成调整大小：将内部数组从150862个元素调整为312874个元素所需的时间。如果您认为每个元素都是通过Array.CopyTo（）顺序复制的，那就不太糟糕了。

填充总时间：由于日志记录和我添加到源中的OnResize事件，确实存在偏差；然而，在操作期间填充300k个整数并调整大小15次仍然令人印象深刻。只是出于好奇，如果我已经知道容量，那么总的填充时间是多少？13毫秒

那么，现在，如果Entry是一个类呢？这些时间或指标真的会有那么大的不同吗？

容量：312874内存大小：2660827字节完成调整大小：26ms填充总时间：964ms

显然，最大的区别在于调整大小。如果字典是用容量初始化的，有什么区别吗？不够关心。。。12毫秒。

所发生的是，由于Entry是一个结构，它不需要像引用类型那样进行初始化。这既是价值类型的美，也是价值类型的祸根。为了使用Entry作为引用类型，我必须插入以下代码：

/*
 *  Added to satisfy initialization of entry elements --
 *  this is where the extra time is spent resizing the Entry array
 * **/
for (int i = 0 ; i < prime ; i++)
{
    destinationArray[i] = new Entry( );
}
/*  *********************************************** */  

我必须将Entry的每个数组元素初始化为引用类型的原因可以在MSDN：Structure Design中找到。简而言之：

不要为结构提供默认构造函数。如果结构定义了默认构造函数结构，公共语言运行时自动对每个数组元素执行默认构造函数。某些编译器（如C#编译器）不允许结构具有默认构造函数。

这其实很简单，我们可以借用阿西莫夫的《机器人三定律》：

结构必须安全才能使用结构必须有效地执行其功能，除非这会违反规则#1结构在使用过程中必须保持完整，除非需要对其进行销毁以满足规则#1

…我们从中得到了什么：简而言之，对价值类型的使用负责。它们快速高效，但如果维护不当（即无意复制），则能够导致许多意外行为。

这是一条基本规则。

如果所有成员字段都是值类型，则创建一个结构。如果任何一个成员字段是引用类型，请创建一个类。这是因为引用类型字段无论如何都需要堆分配。

Exmaples公司

public struct MyPoint 
{
    public int X; // Value Type
    public int Y; // Value Type
}

public class MyPointWithName 
{
    public int X; // Value Type
    public int Y; // Value Type
    public string Name; // Reference Type
}

当您需要值语义而不是引用语义时，请使用结构。

如果需要引用语义，则需要类而不是结构。

Struct可用于提高垃圾收集性能。虽然您通常不必担心GC性能，但在某些情况下，它可能是一个杀手。就像低延迟应用程序中的大型缓存。请参阅本帖中的示例：

http://00sharp.wordpress.com/2013/07/03/a-case-for-the-struct/

除了常见的性能差异之外，让我再补充一个方面，那就是默认值的使用意图。

如果其字段的默认值不表示建模概念的合理默认值，请不要使用结构。

Eg.

即使所有字段都设置为默认值，“颜色”或“点”也有意义。RGB 0,0,0是一种非常好的颜色，（0,0）作为2D中的点也是如此。但是Address或PersonName没有合理的默认值。我的意思是，你能理解FirstName=null和LastName=null的PersonName吗？

如果你用一个类实现了一个概念，那么你可以强制执行某些不变量，例如一个人必须有名字和姓氏。但对于结构，总是可以创建一个实例，将其所有字段设置为默认值。

因此，当对没有合理默认值的概念进行建模时，更喜欢类。类的用户会明白null意味着没有指定PersonName，但如果您给他们一个PersonName结构实例，并将其所有财产设置为null，他们会感到困惑。

（通常的免责声明：性能考虑可能会凌驾于此建议之上。如果您有性能问题，请在决定解决方案之前进行衡量。试试BenchmarkDotNet，这很好！）

以下是在Microsoft网站上定义的规则：

✔️ 如果类型的实例很小且通常很短，或者通常嵌入在其他对象中，请考虑定义结构而不是类。

❌ 避免定义结构，除非该类型具有以下所有特征：

它在逻辑上表示单个值，类似于原始类型（int、double等）。

它的实例大小小于16字节。

它是不可变的。

它不必经常装箱。

供进一步阅读