哪个更容易：字节还是字符？

任何优化的第一条规则是：先测量，然后优化。

不，不是那样的：首先衡量，然后思考，然后优化。

再说一次，不是这样：首先用真实数据测量真实场景，然后思考，然后尝试优化，然后检查这些变化在真实数据的真实场景中发挥作用，然后才最终决定是否需要这样做或者那个优化。

现在的问题。更准确地说，答案是：

您应该使用 enum 因为它最适合列出多个元素：

public enum GameState { Play, Lose, Win }

默认情况下，此枚举实例的大小为 4 个字节。但这可以解决：

public enum GameState:byte { Play, Lose, Win }

但是这里的一切都不是那么简单（这就是为什么您首先需要在实际条件下进行测量）。

public class SomeClass
{
   private GameState _state;
   private string _name;
}

在这种情况下，大小SomeClass将为（64 位 .NET）：ObjectHeader（16 字节）+ 16 字节。因为会有对齐。在 32 位 .NET 上，它将是 8 + 8。

在这里，您可以了解我们GameState可以将什么放入结构中并用于Pack=1使结构的尺寸更小。但是，几乎可以肯定的是，只有当此类对象的数量不是数百万时，匹配才会节省。但即使有数百万个这样的对象，这些技巧也会减慢执行速度，因为访问未对齐字段的效率较低。

一般来说，作为结论：使用枚举，因为这是最适合用于此任务的方法。并且忘记性能，直到它成为一个问题并用探查器证明。

按地点

byte- 占用 8 位，

char- 16 位，因为它存储一个 Unicode 字符（16 位），

这是没有优化的。如果你考虑到 C# 环境的优化，这将取决于你使用这些数据的上下文，如果你只是将它们存储在堆栈上，那么它们甚至可以占用相同的位置，如果是数组，那么它byte会更小。但这是指示性的，因为 C# 环境中的优化在不同平台上的行为可能不同，并且并非所有内容都在那里记录。

但是在实际应用中不需要挤最大值，通常是用来enum存储一个值列表中的变量，默认存储在内存中int，但也可以配置其他存储选项，例如这里byte的描述. 在处理器级别，我认为就速度而言，它很可能是相同的。但就方便性而言enum，它肯定更好，因为它提供了使用枚举的接口。

补充：我再次阅读您的问题，并意识到在您的游戏中这个变量很可能会存储一次，这意味着速度和内存大小不会有差异。除非您正在制作匹配结果的数据库。因此enum。