【发布时间】：2010-10-08 00:27:11
【问题描述】：
Const 被嵌入到客户端代码中。 Readonly 不是。但是const 更快。不过可能只有一点点。
问题是，是否有任何情况下您应该更喜欢const 而不是readonly？或者换种说法，我们实际上总是最好使用readonly 而不是const（记住上面所说的烘焙）？
【问题讨论】：
【发布时间】：2010-10-08 00:27:11
【问题描述】：
我发现 const 的一个特殊用途是属性中使用的可重用“魔术”字符串，因为它们只能是 const，所以不能使用静态只读。
我的特殊用例是 ASP.NET 授权属性
[Authorize(Roles = Roles.FirstParty)]
【讨论】：
当您的字段是简单类型（数字、布尔值或字符串）并且它们的值永远不会更改时，请使用const。如果更改它们的值，则应重新编译项目。
使用readonly 字段当它们从另一个源初始化时（文件、数据库或其他代码，..等），但它们不会被更改。
您希望所有实例共享static readonly 字段。
【讨论】：
我通常只将 const 用于我知道不会永远改变的事情，例如真空中的光速。
对于可能可能更改的内容，我更喜欢只读。这样，如果发生更改，我只需要重新编译一个 dll。这个经验法则的一个例外是变量是否对其自己的程序集是私有的/受保护的/友好的。在这些情况下，使用 const 是安全的。
【讨论】：
-
一个危险的说法——我们在什么环境温度下结冰？ :D
-
我认为在不同的压力下冰点也会发生变化，不是吗？ ;)
const 不能用于类或结构（字符串常量和 null 除外，正如 Skeet 先生指出的那样），只能用于值类型并作为静态字段访问。 const 的值是在编译时设置的，必须在声明时设置。
readonly 可用于除枚举之外的任何内容，并且可以是静态字段或实例字段。 readonly 的值是在运行时设置的，可以根据调用的构造函数进行不同的设置。
Here's a good page 了解 const、readonly 和 static 关键字的概述。
【讨论】：
-
完全不正确。我认为您混淆了您的语言 - 这是 C++。
-
const 可以与引用类型一起使用——只是引用类型常量只有字符串常量和 null。
您应该更喜欢在编译时测试的修饰符，而不是在运行时测试的修饰符（在这种情况下，const 优于 readonly）。而且您应该始终使用支持您需要的语义的修饰符。 如果某些东西不打算修改 - 保护它，否则有人会写一些东西给它（偶然或无知）。
【讨论】：
关于差异的简要概述 在 C# 中的 'const' 和 'readonly' 之间： '常量'：
- 不能是静态的。
- 在编译时评估值。
- 仅在声明时初始化。
'只读'：
- 可以是实例级或静态的。
- 在运行时评估值。
- 可以在声明中初始化，也可以在构造函数中通过代码初始化。
更正：上述状态 const 不能是静态的。那是用词不当。它们不能应用 static 关键字，因为它们已经是静态的。
因此，您将 const 用于要在编译时评估的静态项目。
【讨论】：
-
consts 只是静态的，它们不能使用 static 关键字，因为它是多余的
-
不能是静态的吗？那不是因为它总是是静态的吗？
-
我觉得改一下你原来的说法，比在底部加个“更正”好
-
@Richard：这不是他的原始陈述，而是他引用的。
-
常量默认是静态的
const 的一个很好的用途是用于键/值对的键。例如，如果您仍在使用 AppSetting（而不是 ApplicationSettings），那么加载配置设置的键名实际上没有任何意义。如果在多个地方使用，请将 Key 粘贴在 const 中。
【讨论】：
您可以在 switch 语句中使用 const 值作为 case，fwiw。
【讨论】：
当初始化不直接时，readonly 很有用。
const 可以在编译前确定值时使用。
在某种程度上，readonly 是运行时常量，而 const 是编译时常量值。
编辑：如果您使用 www.koders.com 查看一些代码，您会发现在本来可以使用 const 的地方使用了 readonly。我认为，其背后的原因可能是它可以在构造函数中修改（如果需要）。在 const（尤其是 public）的情况下，您有可能破坏依赖于您的代码的客户端代码。
【讨论】：
我相信“const”唯一合适的时候是当你编写的规范比你正在编写的程序更耐用时。例如，如果您正在实现 HTTP 协议，则为“GET”设置一个 const 成员是合适的，因为它永远不会改变，并且客户端当然可以将其硬编码到他们编译的应用程序中，而不必担心您需要更改以后的价值。
如果您有任何机会在未来版本中更改该值，请不要使用 const。
哦！除非你已经测量过，否则永远不要假设 const 比只读字段快。有 JIT 优化可以做到这一点，所以它实际上是完全一样的。
【讨论】：
-
"如果您有任何机会在未来的版本中更改该值，请不要使用 const。"我没有按照你的逻辑。常量的部分意义在于您可以在未来的版本中更改它。
-
如果一个常量比“internal”更公开（或者如果它只是内部的但你有 InternalsVisibleTo），那么 IL 编译器可以将常量值复制到引用程序集中。这意味着，如果您发布新版本并更改常量，您现在与消费者不同步。
-
@AndrewArnott 感谢您最后的澄清，我敢说这是相当重要的一点！
-
我已经搬到了编码标准似乎有利于 const 的地方。如果您不编写要使用的库，我是否认为这没关系？即您正在编写的应用程序具有 consts 但它最终是已部署的应用程序。
-
当然。如果您正在构建的内容仅部署并且从未链接到可能比您正在构建的内容寿命更长的其他内容，那么您很好。
只要可以在声明中设置值并且不必等待构造函数，就应该使用 const。
【讨论】：
-
这里肯定还有其他需要考虑的警告。 See also here.