我使用结构来打包或解包任何类型的二进制通信格式。这包括读取或写入磁盘、DirectX顶点列表、网络协议或处理加密/压缩数据。

在这方面，你列出的三条准则对我来说并不有用。当我需要以特殊顺序写出400字节的内容时，我将定义一个400字节的结构，并用它应该具有的任何不相关的值填充它，我将以当时最合理的方式设置它。（好吧，四百字节会很奇怪——但当我以写Excel文件为生的时候，我处理的是多达四十字节的结构，因为这就是一些BIFF记录的大小。）

神话1：结构是轻量级类

这个神话有多种形式。有些人认为价值类型不能或不应该有方法或其他重要的行为，它们应该简单地使用数据传输类型，只有公共字段或简单的财产。DateTime类型是这是一个很好的反例：就存在而言，它是一种价值类型是有意义的一个基本单位，如数字或字符能够基于其值执行计算。从另一个角度看问题方向，数据传输类型通常应该是引用类型应该基于期望的值或引用类型语义，而不是类型。其他人认为价值类型比参考类型“更轻”性能。事实是，在某些情况下，价值类型更有表现力-它们不需要垃圾收集，除非它们是盒装的，没有类型例如，识别开销，并且不需要取消引用。但在其他方面方法，引用类型是性能更高的参数传递，将值分配给变量、返回值和类似操作只需要4或8个字节即可复制（取决于您运行的是32位还是64位CLR），而不是复制所有数据。想象一下，如果ArrayList是一个“纯”值类型，并且将ArrayList表达式传递给涉及复制其所有数据的方法！在几乎无论如何，性能并不是由这种决定决定的。瓶颈几乎永远不会出现在你认为会出现的地方，在你根据性能做出设计决策之前，你应该衡量不同的选择。值得注意的是，这两种信念的结合也不起作用。它不管一个类型有多少个方法（无论是类还是结构）-每个实例占用的内存不受影响。（内存方面有成本为代码本身占用，但这只发生一次，而不是每个实例。）

神话#2：引用类型存在于堆中；堆栈上存在值类型

这通常是由于重复的人的懒惰造成的部分是正确的，引用类型的实例总是在堆上创建的。这是导致问题的第二部分。正如我已经注意到的，变量的值存在于声明的任何地方，因此，如果您有一个类的实例变量类型为int，那么任何给定对象的变量值将始终位于该对象的其余数据的位置在堆上。仅局部变量（方法中声明的变量）和方法参数存在于堆栈中。在C#2和更高版本中，即使是一些局部变量在堆栈上生存，正如我们在第5章中研究匿名方法时所看到的那样。这些概念现在是否相关？如果您正在编写托管代码，那么应该让运行时考虑内存的最佳使用方式，这是有争议的。事实上，语言规范并不能保证哪里未来的运行时可能能够在堆栈上创建一些对象，如果或者C#编译器可以生成几乎不使用堆栈。下一个神话通常只是一个术语问题。

神话#3：默认情况下，对象在C中通过引用传递

这可能是流传最广的神话。再一次，制造这个的人声明经常（虽然不总是）知道C#的实际行为，但他们不知道“通过引用传递”的真正含义。不幸的是，对于那些知道这意味着什么。引用传递的形式定义相对复杂，涉及l值和类似的计算机科学术语，但重要的是，如果你通过了变量，您调用的方法可以通过更改其参数值来更改调用者变量的值。现在，请记住引用的值类型变量是引用，而不是对象本身。您可以更改参数引用的对象，而不通过引用传递参数本身。例如，以下方法更改StringBuilder的内容对象，但调用方的表达式仍将引用与之前：

void AppendHello(StringBuilder builder)
{
    builder.Append("hello");
}

调用此方法时，参数值（对StringBuilder的引用）为通过值传递。如果要在方法，其中语句builder=null-改变不会是与神话相反。有趣的是，不仅神话中的“引用”部分不准确，而且“对象被传递”部分也不准确。对象本身也不会被传递通过引用或通过值。当涉及引用类型时通过引用传递，或者参数（引用）的值通过值传递。除此之外，这回答了当null为如果正在传递对象，则用作by-value参数，这将导致问题，因为不会有对象要通过！相反，空引用由传递值的方式与任何其他引用相同。如果这个简短的解释让您感到困惑，那么您可能想看看我的文章“在C#中传递参数”(http://mng.bz/otVt)，其中包含更多内容细节这些神话并不是唯一的神话。拳击和拆箱是他们的我会努力澄清这一误解。

参考：Jon Skeet的C#深度第三版

无论何时：

不需要多态性，want值语义，以及希望避免堆分配和相关的垃圾收集开销。

然而，需要注意的是，结构（任意大）传递比类引用（通常是一个机器字）更昂贵，因此类在实践中可能会更快。

C#或其他.net语言中的结构类型通常用于保存应该表现为固定大小的值组的内容。结构类型的一个有用方面是，可以通过修改保存结构类型实例的存储位置来修改该实例的字段，而不是以其他方式。可以以这样的方式对结构进行编码，即变异任何字段的唯一方法是构造一个完整的新实例，然后使用结构赋值通过用新实例中的值覆盖目标的所有字段来对其进行变异，但除非结构不提供创建其字段具有非默认值的实例的方法，如果结构本身存储在可变位置，则其所有字段都是可变的。

请注意，如果结构包含一个私有类类型字段，那么可以设计一个结构类型，使其基本上表现为类类型，并将其自身成员重定向到包装的类对象的成员。例如，PersonCollection可能提供财产SortedByName和SortedById，这两个属性都持有对PersonCollection的“不可变”引用（在其构造函数中设置），并通过调用creator.GetNameSortedEnumerator或creator.GetIdSortedEnumerator来实现GetEnumerater。此类结构的行为与对PersonCollection的引用非常相似，除了它们的GetEnumerator方法将绑定到PersonCollection中的不同方法。也可以有一个结构来包裹数组的一部分（例如，可以定义一个ArrayRange＜T＞结构，该结构将保存一个称为Arr的T[]、一个int Offset和一个int Length，以及一个索引属性，对于范围0到Length-1的索引idx，该属性将访问Arr[idx+Offset]）。不幸的是，如果foo是这种结构的只读实例，当前的编译器版本将不允许像foo[3]+=4这样的操作；因为它们无法确定这些操作是否会尝试写入foo的字段。

也可以设计一个结构，使其行为类似于一个值类型，该值类型包含一个可变大小的集合（无论何时该结构都会被复制），但唯一可行的方法是确保该结构包含引用的对象不会暴露于任何可能使其发生变异的对象。例如，可以有一个类似数组的结构，它保存一个私有数组，其索引的“put”方法创建一个新数组，其内容与原始数组的内容相似，只有一个元素发生了更改。不幸的是，要使这种结构有效地执行可能有些困难。虽然有时结构语义可能很方便（例如，能够将类似数组的集合传递给例程，调用方和被调用方都知道外部代码不会修改集合，这可能比要求调用方和受调用方防御性地复制它们所提供的任何数据要好），类引用指向永远不会变异的对象的要求通常是一个相当严格的约束。

C#结构是类的轻量级替代。它可以做的几乎与类相同，但使用结构而不是类的“成本”更低。这样做的原因有点技术性，但总而言之，类的新实例放在堆上，新实例化的结构放在堆栈上。此外，您不是像处理类那样处理对结构的引用，而是直接处理结构实例。这也意味着，当您将结构传递给函数时，它是按值传递的，而不是作为引用。在关于函数参数的章节中有更多关于这一点的内容。

因此，当您希望表示更简单的数据结构时，尤其是如果您知道要实例化大量数据结构，那么应该使用结构。在.NET框架中有很多示例，其中Microsoft使用了结构而不是类，例如Point、Rectangle和Color结构。

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

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