前一段时间，我在微软做一个项目，当时微软。net CLR产品团队的人来拜访我们。这个人编写了例子，当他定义变量时，他使用“Int32”与“int”和“String”与“String”。

我记得在微软的其他示例代码中见过这种样式。所以，我做了一些研究，发现每个人都说“Int32”和“int”之间没有区别，除了语法着色。事实上，我发现很多材料都建议您使用“Int32”使您的代码更具可读性。所以，我采用了这种风格。

前几天我确实发现了不同!编译器不允许你使用" Int32 "输入enum，但当你使用" int "时，它允许你输入enum。别问我为什么，因为我还不知道。

例子:

public  enum MyEnum : Int32
{
    AEnum = 0
}

这个作品。

public enum MyEnum : int
{
    AEnum = 0
}

取自:Int32符号vs. int

int是一个c#关键字，是明确的。

大多数情况下，这并不重要，但有两件事与Int32相悖:

您需要有一个“using System;”语句。使用"int"不需要Using语句。 可以定义自己的名为Int32的类(这将是愚蠢和令人困惑的)。Int总是Int的意思。

我使用int是为了防止Microsoft将整数的默认实现更改为一些新版本(我们称其为Int32b)。

然后，Microsoft可以将int别名更改为Int32b，我不需要更改任何代码就可以利用他们新的(希望是改进的)整数实现。

这同样适用于任何类型关键字。

你不应该在意。如果大小是一个问题，我会使用字节，短，int，然后长。使用int型比int32大的唯一原因是需要一个大于2147483647或小于-2147483648的数。

除此之外，我不在乎，还有很多其他的事情需要关心。

当您只需要处理一种语言时，类型的字节大小就不太有趣了(对于那些不需要提醒自己数学溢出的代码)。有趣的部分是当你在一种语言和另一种语言之间建立桥梁，c#到COM对象，等等，或者你正在做一些位转移或屏蔽，你需要提醒自己(和你的代码审查同事)数据的大小。

在实践中，我通常使用Int32来提醒自己它们的大小，因为我确实写托管c++(例如桥接到c#)以及非托管/本机c++。

你可能知道，在c#中是64位，但在原生c++中，它最终是32位，或者char是unicode/16位，而在c++中是8位。但是我们是怎么知道的呢?答案是，因为我们已经在手册上查过了，上面是这么说的。

随着时间的推移和经验的积累，当你在c#和其他语言之间编写代码时，你会开始更加注重类型(这里的一些读者会想“为什么你会这样做?”)，但恕我直言，我认为这是一个更好的实践，因为我不记得我上周写了什么(或者我不必在我的API文档中指定“此参数是32位整数”)。

在f#中(尽管我从未使用过它)，它们定义了int, int32和nativeint。同样的问题也会出现，“我该用哪一个?”正如其他人所提到的，在大多数情况下，它不应该是重要的(应该是透明的)。但我个人会选择int32和uint32来消除歧义。

我想这取决于你在编写什么应用程序，谁在使用它，你和你的团队遵循什么编码实践，等等，来证明什么时候使用Int32。

附录: 顺便说一句，自从我几年前回答了这个问题之后，我就开始同时使用f#和Rust了。f#，它都是关于类型推断，以及c#和f#之间的桥接/互操作，本机类型匹配，所以不用担心;我很少需要在f#中显式地定义类型(如果不使用类型推断，这几乎是一种罪过)。在Rust中，他们完全消除了这种歧义，你必须使用i32 vs u32;总而言之，减少歧义有助于减少bug。

一些编译器在不同的平台上对int有不同的大小(不是c#特定的)

一些编码标准(MISRA C)要求所有使用的类型都指定大小(即Int32而不是int)。

为不同类型的变量指定前缀也很好(例如，b表示8位字节，w表示16位字，l表示32位长字=> Int32 lMyVariable)

您应该关心，因为它使您的代码更具可移植性和可维护性。

如果你总是要使用c#，而且c#规范在这方面永远不会改变，那么可移植可能不适用于c#。

可维护的ihmo将始终适用，因为维护代码的人可能不知道这个特定的c#规范，并且错过了int偶尔超过2147483647的错误。

在简单的for循环中，例如计算一年中的月份，您不会关心，但是当您在一个可能会owerflow的上下文中使用该变量时，您应该关心。

您还应该注意是否要对它进行逐位操作。