如前所述，int = Int32。为了安全起见，请确保始终使用int. minvalue /int。MaxValue在实现任何关心数据类型边界的东西时。假设. net决定int现在是Int64，那么你的代码就不那么依赖于边界了。

根据我的经验，这是一种惯例。我不知道在Int32上使用int的任何技术原因，但它是:

打字更快。 对于典型的c#开发人员来说更加熟悉。 默认visual studio语法高亮显示的不同颜色。

我特别喜欢最后一个。：）

当您只需要处理一种语言时，类型的字节大小就不太有趣了(对于那些不需要提醒自己数学溢出的代码)。有趣的部分是当你在一种语言和另一种语言之间建立桥梁，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。它将有助于将来将程序移植到更广泛的体系结构(目前int是System的别名。Int32，但这可能会改变)。只有当变量的位宽很重要时(例如:要控制结构体在内存中的布局)，才应该使用int32和其他变量(与"using System;"相关联)。

我总是使用系统类型——例如，Int32而不是int。我在阅读了Applied . net Framework Programming之后采用了这种做法——作者Jeffrey Richter为使用完整类型名做了一个很好的例子。以下两点让我印象深刻:

Type names can vary between .NET languages. For example, in C#, long maps to System.Int64 while in C++ with managed extensions, long maps to Int32. Since languages can be mixed-and-matched while using .NET, you can be sure that using the explicit class name will always be clearer, no matter the reader's preferred language. Many framework methods have type names as part of their method names: BinaryReader br = new BinaryReader( /* ... */ ); float val = br.ReadSingle(); // OK, but it looks a little odd... Single val = br.ReadSingle(); // OK, and is easier to read

现在是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和所有其他变体?这意味着什么?