嗯…

I wouldn't use garbage collection as an argument for/against the use of structs vs classes. The managed heap works much like a stack - creating an object just puts it at the top of the heap, which is almost as fast as allocating on the stack. Additionally, if an object is short-lived and does not survive a GC cycle, deallocation is free as the GC only works with memory that's still accessible. (Search MSDN, there's a series of articles on .NET memory management, I'm just too lazy to go dig for them).

大多数情况下，我使用结构体时，都会后悔这样做，因为我后来发现使用引用语义会让事情更简单一些。

无论如何，上面的MSDN文章中的这四点似乎是一个很好的指导方针。

当您不需要行为，但需要比简单的数组或字典更多的结构时。

跟进 这就是我对结构体的一般看法。我知道他们可以有方法，但我喜欢保持整体的精神区分。

当我想要将几个值组合在一起以从方法调用中传递内容时，我总是使用结构体，但在读取这些值之后，我将不需要将它用于任何事情。只是为了保持干净。我倾向于将struct中的东西视为“扔掉的”，而将类中的东西视为更有用和“功能性的”

If an entity is going to be immutable, the question of whether to use a struct or a class will generally be one of performance rather than semantics. On a 32/64-bit system, class references require 4/8 bytes to store, regardless of the amount of information in the class; copying a class reference will require copying 4/8 bytes. On the other hand, every distinct class instance will have 8/16 bytes of overhead in addition to the information it holds and the memory cost of the references to it. Suppose one wants an array of 500 entities, each holding four 32-bit integers. If the entity is a structure type, the array will require 8,000 bytes regardless of whether all 500 entities are all identical, all different, or somewhere between. If the entity is a class type, the array of 500 references will take 4,000 bytes. If those references all point to different objects, the objects would require an additional 24 bytes each (12,000 bytes for all 500), a total of 16,000 bytes--twice the storage cost of a struct type. On the other hand, of the code created one object instance and then copied a reference to all 500 array slots, the total cost would be 24 bytes for that instance and 4,000 for the array--a total of 4,024 bytes. A major savings. Few situations would work out as well as the last one, but in some cases it may be possible to copy some references to enough array slots to make such sharing worthwhile.

如果实体应该是可变的，那么使用类还是结构的问题在某些方面会更容易。假设“Thing”是一个具有整数字段x的结构体或类，并执行以下代码:

  Thing t1,t2;
  ...
  t2 = t1;
  t2.x = 5;

是否希望后一种说法影响t1.x?

如果Thing是类类型，t1和t2将等效，即t1。X和t2。X也是等价的。因此，第二个语句将影响t1.x。如果Thing是一个结构类型，t1和t2将是不同的实例，即t1。X和t2。X表示不同的整数。因此，第二个语句不会影响t1.x。

Mutable structures and mutable classes have fundamentally different behaviors, though .net has some quirks in its handling of struct mutations. If one wants value-type behavior (meaning that "t2=t1" will copy the data from t1 to t2 while leaving t1 and t2 as distinct instances), and if one can live with the quirks in .net's handling of value types, use a structure. If one wants value-type semantics but .net's quirks would cause lead to broken value-type semantics in one's application, use a class and mumble.

正如@Simon所说，结构体提供了“值类型”语义，所以如果你需要类似于内置数据类型的行为，可以使用结构体。由于结构体是通过复制传递的，所以要确保它们的大小很小，大约16字节。

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