什么时候应该在C#中使用结构而不是类？我的概念模型是，当项只是值类型的集合时，使用结构。一种将它们逻辑地结合在一起的方法。
我在这里遇到了这些规则：
结构应表示单个价值结构应具有内存占用空间小于16字节。结构不应在之后更改创造
这些规则有效吗？结构在语义上意味着什么？
当前回答
我认为一个好的第一近似值是“从不”。
我认为一个好的二次近似是“从不”。
如果你渴望表现，那么考虑一下，但始终要衡量。
其他回答
在需要使用StructLayoutAttribute显式指定内存布局（通常用于PInvoke）的情况下，需要使用“结构”。
编辑：注释指出，可以将类或结构与StructLayoutAttribute一起使用，这当然是正确的。在实践中，您通常会使用一个结构——它是在堆栈上分配的，而不是在堆上分配的——如果您只是向非托管方法调用传递一个参数，这是有意义的。
第一：互操作场景或需要指定内存布局时
第二：当数据大小与引用指针几乎相同时。
我刚刚在处理Windows Communication Foundation[WCF]命名管道，我注意到使用Structs确实有意义，以确保数据交换是值类型而不是引用类型。
C#结构是类的轻量级替代。它可以做的几乎与类相同，但使用结构而不是类的“成本”更低。这样做的原因有点技术性，但总而言之，类的新实例放在堆上，新实例化的结构放在堆栈上。此外，您不是像处理类那样处理对结构的引用，而是直接处理结构实例。这也意味着，当您将结构传递给函数时，它是按值传递的，而不是作为引用。在关于函数参数的章节中有更多关于这一点的内容。
因此，当您希望表示更简单的数据结构时，尤其是如果您知道要实例化大量数据结构，那么应该使用结构。在.NET框架中有很多示例，其中Microsoft使用了结构而不是类，例如Point、Rectangle和Color结构。
我不同意原帖子中给出的规则。以下是我的规则：
当存储在数组中时，可以使用结构来提高性能。（另请参见结构何时是答案？）在向C/C传递结构化数据的代码中需要它们++除非需要，否则不要使用结构：它们的行为与赋值下的“正常对象”（引用类型）不同当作为参数传递时，这可能导致意外行为；如果查看代码的人不知道他们正在处理一个结构。它们不能被继承。将结构作为参数传递比类更昂贵。
