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

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

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

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

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

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

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

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

现在是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是c#语言中System的快捷方式。Int32

虽然这确实意味着微软可能会改变这种映射，但FogCreek讨论的一篇文章指出[来源]

“关于64位的问题——微软确实在开发64位版本的。net框架，但我很确定int不会在该系统上映射到64位。

原因:

1. c# ECMA标准明确规定int是32位，long是64位。

2. 微软在框架1.1版本中引入了额外的属性和方法，返回长值而不是int值，例如Array。除了Array.GetLength之外的GetLongLength。

所以我认为可以肯定地说，所有内置的c#类型都将保持当前的映射。”

ECMA-334:2006 c#语言规范(p18)

每个预定义类型都是系统提供类型的简写。例如，关键字int指向结构体System.Int32。就风格而言，使用关键字优于使用完整的系统类型名。

还要考虑Int16。如果你需要在应用程序的内存中存储一个Integer类型，并且你关心使用的内存量，那么你可以使用Int16类型，因为它使用的内存更少，并且比Int32类型的最小/最大范围更小(这就是int类型)。

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