我知道最好的做法是使用int，所有MSDN代码都使用int。然而，据我所知，除了标准化和一致性之外，没有其他原因。

int和Int32之间没有区别，但由于int是一个语言关键字，许多人在风格上更喜欢它(就像string vs string)。

前一段时间，我在微软做一个项目，当时微软。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

现在是2021年，我已经看完了所有的答案。大多数人说它基本上是一样的(它是一个别名)，或者，这取决于“你喜欢什么”，或者“按照惯例使用int…”没有答案给你一个明确的时间，地点和为什么使用Int32除以int。我就是为此而来的。

98%的情况下，你可以不使用int，这是完全没问题的。另外的2%是什么?

IO与记录(结构，本机类型，组织和压缩)。有人说，无用的应用程序可以读取和操作数据，但实际上不能将新数据写入已定义的存储。但是为了避免重复工作，在某些时候，那些处理旧数据的人必须检索关于如何读取它们的文档。很有可能它们是在long一直是32位整数的时代编译的。

It happenned before, where some had trouble remembering a db is a byte, a dw is a word, a dd is a double word, but how many bits was that about ? And that will likely happen again on C# 43.0 on a 256-bits platform... where the (future) boys never heard of "by convention, use int instead of Int32". That's the 2% where Int32 matters over int. MSDN saying today it's recommended to use int is irrelevant, it usually works with current C# version, but that may get dropped in future MSDN pages, in 2028, or 2034 ? Fewer and fewer people have WORD and DWORD encouters today, yet, two decades ago, they were common. The same thing will happen to int, in the very case of dealing with precise-fixed-length data.

在内存中，ushort (UInt16)可以是Decimal，只要它的小数部分是空的，它是正的或空的，并且不超过65535。但在文件中，它必须是短的16位长。当您阅读关于来自另一个时代的文件结构的文档时(在源代码中)，您会发现有3545个记录定义，其中一些嵌套在其他记录中，每个记录有几个到数百个不同类型的字段。

Somewhere in 2028 a boy thought he could just get away by Ctrl-H-ing int to Int32, whole word only and match case... ~67000 changes in whole solution. Hit Run and still get CTDs. Clap clap clap. Go figure which int you should have changed to Int32 and which ones you should have changed to var. Also worth to point out Pointers are useful, when you deal with terabytes of datas (have a virtual representation of an entire planet on some cloud, download on demand, and render to user screen). Pointers are really fast in the ~1% of cases where there are so many datas to compute in realtime, you must trade with unsafe code. Again, it's to come up with an actually useful application, instead of being fancy and waste time porting to managed. So, be carefull, IntPtr is 32-bits or 64-bits already ? Could you get away with your code without caring how many bytes you read/skip ? Or just go (Int32*) int32Ptr = (Int32*) int64Ptr;...

一个更真实的例子是一个包含数据处理和它们各自的命令(源代码中的方法)的文件，比如内部分支(如果测试失败，有条件的继续或跳转到):

IfTest record in file says : if value equals someConstant, jump to address. Where address is a 16-bits integer representing a relative pointer inside the file (you can go back towards the start of the file up to 32768 bytes, or up to 32767 bytes further down). But 10 years later, platforms can handle larger files and larger datas, and now you have 32-bits relative address. Your method in the source code were named IfTestMethod(...), now how would you name the new one ? IfTestMethodInt() or IfTestMethod32() ? Would you also rename the old method IfTestMethodShort() or IfTestMethod16() ? Then a decade later, you get a new command with long (Int64) relative address... What about a 128 bits command some 10 years later ? Be consistent ! Principles are great, but sometimes logic is better.

问题不在于我或你今天写的代码，对我们来说似乎没问题。它是在一个人试图理解我们所写的东西的地方，10年或20年后，提出一个工作更新代码需要花费多少时间(=金钱)?明确或写多余的注释实际上会节省时间。你喜欢哪一种?Int32 val;或var val;/ / 32位。

Also, working with foreign data from other platforms or compile directives is a concept (today involves Interop, COM, PInvoke...) And that's a concept we cannot get rid of, whatever the era, because it takes time to update (reformat) datas (via serialization for ex.) Upgrading DLLs to managed code also takes time. We took time to leave assembler behind and go full-C. We are taking time to move from 32-bits datas to 64-bits, yet, we still need to care about 8 and 16-bits. What next in the future ? Move from 128-bits to 256 or directly to 1024 ? Do not assume a keyword explicit to you will remain explicit for the guys reading your documentation 20 years later (and documentation usually contains errors, mainly because of copy/paste).

这就是:今天在哪里使用Int32而不是int ?

It's when you are producing code that is data-size sensible (IO, network, cross-platform data...), and at some point in the future - could be decades later - someone will have to understand and port your code. The key reason is era-based. 1000 lines of code, it's okay to use int, 100000 lines, it's not anymore. That's a rare duty only a few will have to do, and hell yeah, they have struggle, if only some were a little more explicit instead of relying on "by convention" or "it looks pretty in the IDE, Int32 is so ugly" or "they are the same, don't bother, it's a waste of time to write that two numbers and holding shift key", or "int is unambiguous", or "those who don't like int are just VB fanboys - go learn C# you noob" (yeah, that's the underlying meaning of a few comments right here)

不要把我所写的作为一种普遍的看法，也不要试图在所有情况下推广Int32。我清楚地陈述了具体的情况(在我看来，从其他答案中不清楚这一点)，以支持少数人因为编写Int32而受到主管的指责，同时也是同一个主管不理解为什么要花这么长时间将C DLL重写为c#。这是一个边缘情况，但至少对于那些阅读“Int32”的人来说，它的生命中至少有一个目的。

这一点可以通过另一种方式进一步讨论:为什么不在未来的c#规范中摆脱Int32、Int64和所有其他变体?这意味着什么?

我知道最好的做法是使用int，所有MSDN代码都使用int。然而，据我所知，除了标准化和一致性之外，没有其他原因。

你不应该在乎。大多数时候你应该使用int。它将有助于将来将程序移植到更广泛的体系结构(目前int是System的别名。Int32，但这可能会改变)。只有当变量的位宽很重要时(例如:要控制结构体在内存中的布局)，才应该使用int32和其他变量(与"using System;"相关联)。