Const被烘焙到客户机代码中。Readonly不是，但Const更快。可能只是轻微的。

问题是，有没有哪种情况下，你更喜欢Const而不是Readonly？或者换句话来说，我们使用Readonly而不是Const不是更好吗(记住上面提到的烘焙方式)？

我相信"const"唯一合适的时间是当有一个规范，您根据它进行编码比您正在编写的程序更持久。例如，如果您正在实现HTTP协议，那么让一个const成员作为"get"是合适的，因为它永远不会改变，而且客户机当然可以将其硬编码到已编译的应用程序中，而不用担心您以后需要更改该值。

如果您有任何机会需要在未来版本中更改该值，请不要使用const。

哦！除非您已经测量了常量，否则不要假设常量比只读字段快。有一些JIT优化可能会使它变得完全相同。

常量与只读：

A quick synopsis on the differences
between 'const' and 'readonly' in C#:
'const':

• Can't be static.
• Value is evaluated at compile time.
• Initiailized at declaration only.

'readonly':

• Can be either instance-level or static.
• Value is evaluated at run time.
• Can be initialized in declaration or by code in the constructor.

更正：上面的状态常量不能是静态的。这是一个用词不当的词。它们不能应用静态关键字，因为它们已经是静态的。

因此，对于要在编译时计算的静态项，可以使用const。

在switch语句fwiw中，可以使用const值。

我通常只对我知道永远不会改变的东西使用const，比如真空中的光速。

对于可能发生变化的事物，我更喜欢只读。这样，如果发生更改，我只需要重新编译一个DLL。这个经验法则的一个例外是，如果变量是私有的/受保护的/对它自己的程序集友好的。在这种情况下，使用const是安全的。

当初始化不是直接进行时，readonly非常有用。当您在编译前确定该值时，可以使用const。

在某种程度上，readonly是运行时const&const是编译时常量值。

编辑：如果您使用www.koders.com查看一些代码，您会发现在可能使用const的地方使用了readonly。我认为，这背后的原因可能是它在构造函数中是可修改的(如果需要的话)。对于const(特别是public)，您有机会根据代码破坏客户机代码。

const不能用于类或结构(字符串常量和空除外，正如skeet先生指出的那样)，只能用于值类型，并且作为静态字段访问。常量值在编译时设置，并且在声明时必须设置。

readonly可以用于除枚举之外的任何内容，可以是静态字段或实例字段。只读的值是在运行时设置的，可以根据调用的构造函数进行不同的设置。

下面是一个很好的页面，可以大致了解const、readonly和static关键字。

您应该更喜欢在编译时测试的修饰符，而不是在运行时测试的修饰符(在此上下文中，const比readonly)。您应该始终使用支持所需语义的修饰符。如果某个东西不打算被修改——保护它，或者有人会给它写东西(偶然或无知)。

当您的字段是简单类型(数字、布尔值或字符串)并且其值永远不会更改时，请使用const。如果更改它们的值，则应重新编译项目。

当从另一个源(文件、数据库或其他代码等)初始化时，使用readonly字段，但不会更改它们。

当您想让所有实例共享时，使用static readonly字段。

const的一个好用法是用于键/值对的键。例如，如果您仍在使用appsetting(而不是applicationsettings)，那么将密钥的名称加载到配置设置中是没有意义的。如果在多个地方使用，将钥匙插入常量。

只要可以在声明中设置值并且不必等待构造函数，就应该使用const。