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

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

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

这两者确实是同义的;int看起来会更熟悉一些，Int32让那些阅读你的代码的人更清楚地看到32位。我倾向于在我只需要“一个整数”的地方使用int，在大小很重要的地方使用Int32(密码代码，结构)，这样未来的维护者就会知道在适当的情况下扩大int是安全的，但应该注意以同样的方式改变Int32。

结果代码将是相同的:区别纯粹是可读性或代码外观。

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

int和Int32是一样的。int是Int32的别名。

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

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

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

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

int与System相同。Int32，当编译时，它将在CIL中变成相同的东西。

我们在c#中按照惯例使用int，因为c#希望看起来像C和c++(以及Java)，这就是我们在那里使用的……

顺便说一句，我最终使用的是系统。Int32时声明各种Windows API函数的导入。我不确定这是否是一个定义的约定，但它提醒我，我要去一个外部DLL…

int可以保存的字节数取决于你编译它的目的，所以当你为32位处理器编译程序时，它可以保存从2^32/2到-2^32/2+1的数字，而为64位编译时，它可以保存从2^64/2到-2^64/2+1的数字。Int32总是包含2^32个值。

编辑:忽略我的回答，我没有看到c#。我的答案是针对C和c++的。我从来没用过c#

这在实践中没有什么区别，最终你会采用你自己的惯例。我倾向于在分配类型时使用关键字，在使用静态方法时使用类版本等:

int total = Int32.Parse("1009");

你不应该关心大多数编程语言，除非你需要编写非常特定的数学函数，或者针对特定架构优化的代码……只要确保类型的大小足够你(例如，如果你知道你需要超过32位，就使用比Int更大的类型)

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

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

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

没关系。int是语言关键字，Int32是实际的系统类型。

也可以在这里看到我对相关问题的回答。

曾经，int数据类型与编译器目标机器的寄存器大小挂钩。例如，16位系统的编译器将使用16位整数。

然而，谢天谢地，我们已经很少看到16位了，当64位开始流行时，人们更关心的是使它与旧软件兼容，32位已经存在了很长时间，对于大多数编译器来说，int只是假设为32位。

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。就风格而言，使用关键字优于使用完整的系统类型名。

它们都声明了32位整数，正如其他作者所述，使用哪一个主要是语法风格的问题。然而，他们并不总是以同样的方式表现。例如，c#编译器不允许这样做:

public enum MyEnum : Int32
{
    member1 = 0
}

但是它允许这样做:

public enum MyEnum : int
{
    member1 = 0
}

图。

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

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

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

当您只需要处理一种语言时，类型的字节大小就不太有趣了(对于那些不需要提醒自己数学溢出的代码)。有趣的部分是当你在一种语言和另一种语言之间建立桥梁，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是System的别名。Int32，定义如下: 内置类型表(c#参考)

使用Int32类型需要对System或完全限定(System.Int32)的命名空间引用。我倾向于int，因为它不需要名称空间导入，因此在某些情况下减少了名称空间冲突的机会。当编译为IL时，两者之间没有区别。

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

我总是使用系统类型——例如，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

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

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

虽然它们(大部分)是相同的(参见下面的一个[错误]差异)，但您绝对应该注意并应该使用Int32。

The name for a 16-bit integer is Int16. For a 64 bit integer it's Int64, and for a 32-bit integer the intuitive choice is: int or Int32? The question of the size of a variable of type Int16, Int32, or Int64 is self-referencing, but the question of the size of a variable of type int is a perfectly valid question and questions, no matter how trivial, are distracting, lead to confusion, waste time, hinder discussion, etc. (the fact this question exists proves the point). Using Int32 promotes that the developer is conscious of their choice of type. How big is an int again? Oh yeah, 32. The likelihood that the size of the type will actually be considered is greater when the size is included in the name. Using Int32 also promotes knowledge of the other choices. When people aren't forced to at least recognize there are alternatives it become far too easy for int to become "THE integer type". The class within the framework intended to interact with 32-bit integers is named Int32. Once again, which is: more intuitive, less confusing, lacks an (unnecessary) translation (not a translation in the system, but in the mind of the developer), etc. int lMax = Int32.MaxValue or Int32 lMax = Int32.MaxValue? int isn't a keyword in all .NET languages. Although there are arguments why it's not likely to ever change, int may not always be an Int32.

缺点是要多输入两个字符和[bug]。

这不会编译

public enum MyEnum : Int32
{
    AEnum = 0
}

但这将:

public enum MyEnum : int
{
    AEnum = 0
}

使用Int或Int32都是一样的Int只是为了简化读者的代码。

使用可空变量Int?还是Int32 ?当您在数据库中处理包含null的字段时。这将使您避免大量的运行时问题。

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

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

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

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

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

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

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

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

我总是在定义变量时使用别名类型(int, string等)，在访问静态方法时使用真实名称:

int x, y;
...
String.Format ("{0}x{1}", x, y);

看到像int.TryParse()这样的东西似乎很难看。除了风格，我这么做没有别的原因。

我建议使用微软的StyleCop。

它类似于FxCop，但用于与样式相关的问题。默认配置与微软的内部样式指南相匹配，但也可以根据您的项目进行定制。

它可能需要一些时间来适应，但它肯定会使您的代码更好。

您可以将它包含在构建过程中，以自动检查是否违反。

根据Visual Studio 2012中的即时窗口，Int32是int型，Int64是long型。输出如下:

sizeof(int)
4
sizeof(Int32)
4
sizeof(Int64)
8
Int32
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648
Int64
long
    base {System.ValueType}: System.ValueType
    MaxValue: 9223372036854775807
    MinValue: -9223372036854775808
int
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648

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