现在是 2021 年，我已阅读所有答案。大多数人说它基本上是一样的（它是一个别名），或者，它取决于“你喜欢什么”，或者“按照惯例使用 int ...”没有答案给你一个明确的何时，在哪里和为什么使用Int32而不是int。这就是我在这里的原因。
98% 的情况下，您都可以使用int，这完全没问题。 剩下的 2% 是多少？
带记录的 IO（结构、原生类型、组织和压缩）。有人说一个无用的应用程序是一个可以读取和操作数据，但实际上不能将新数据写入定义存储的应用程序。但为了不重新发明轮子，在某些时候，那些处理旧数据的人必须检索有关如何阅读它们的文档。很可能它们是从 long 始终是 32 位整数的时代编译的。
以前发生过，有些人记不住db 是一个字节，dw 是一个字，dd 是一个双字，但那是多少位？而且这可能会再次发生在C# 43.0256-bits 平台上......（未来）男孩从未听说过“按照惯例，使用 int 而不是 Int32”。这是Int32 比int 重要的2%。 MSDN 今天说建议使用 int 无关紧要，它通常适用于当前的 C# 版本，但在未来的 MSDN 页面中，可能会在 2028 年或 2034 年被丢弃？今天拥有WORD 和DWORD 的人越来越少，然而，在二十年前，它们很常见。在处理精确固定长度数据的情况下，int 也会发生同样的事情。
在内存中，ushort（UInt16）可以是Decimal，只要它的小数部分为空，为正或空，不超过65535。但在文件中，它必须是short，16 位长。当您阅读有关另一个时代的文件结构的文档（在源代码中）时，您会意识到 有 3545 条记录定义，其中一些嵌套在其他记录中，每条记录之间都有一对 数百个不同类型的字段。
在 2028 年的某个地方，一个男孩认为 他可以通过 Ctrl-H-ing int 到 Int32，仅使用整个单词并匹配大小写... ~67000 整个解决方案的变化.点击运行，仍然获得 CTD。拍拍拍拍。看看哪个int 你应该改成Int32 哪些你应该改成var。同样值得指出的是，Pointers 在处理 TB 级数据时很有用（在某个云上拥有整个星球的虚拟表示，按需下载并渲染到用户屏幕）。在大约 1% 的情况下，指针非常快，因为需要实时计算大量数据，您必须使用不安全的代码进行交易。同样，它要提出一个实际有用的应用程序，而不是花哨并浪费时间移植到托管。所以，要小心，IntPtr 已经是 32 位还是 64 位了？您可以在不关心您读取/跳过多少字节的情况下摆脱您的代码吗？或者直接去(Int32*) int32Ptr = (Int32*) int64Ptr;...
一个更实际的例子是一个包含数据处理及其各自命令（源代码中的方法）的文件，例如内部分支（如果测试失败则有条件地继续或跳转到）：
IfTest 文件中的记录说：如果 value 等于 someConstant，则跳转到 address。其中address 是一个16-bits 整数，表示文件内的相对指针（您可以返回文件开头最多32768 个字节，或向下最多32767 个字节）。但是 10 年后，平台可以处理更大的文件和更大的数据，现在你有了32-bits 相对地址。您在源代码中的方法命名为IfTestMethod(...)，现在您将如何命名新方法？ IfTestMethodInt() 或 IfTestMethod32() ？您还会重命名旧方法 IfTestMethodShort() 或 IfTestMethod16() 吗？然后十年后，您会得到一个具有长（Int64）相对地址的新命令......大约 10 年后的 128 位命令呢？ 保持一致！原则很好，但有时逻辑更好。
问题不在于我或您今天编写代码，对我们来说似乎没问题。它代替了一个人试图理解我们写的东西，10 或 20 年后，需要多少时间及时（=钱）来有一个有效的更新代码？显式或编写冗余的 cmets 实际上会节省时间。你更喜欢哪一个？ Int32 val; 或 var val; // 32-bits。
另外，使用来自其他平台的外部数据或编译指令是一个概念（今天涉及Interop、COM、PInvoke...）这是一个概念我们无法摆脱，无论哪个时代，因为更新（重新格式化）数据（例如通过序列化）需要时间。将 DLL 升级到托管代码也需要时间。我们花了一些时间把汇编程序抛在脑后，转而使用全 C。我们正在花时间从 32 位数据转移到 64 位，但是，我们仍然需要关心 8 位和 16 位。未来的下一步是什么？从 128 位移动到 256 或直接移动到 1024？不要假设一个明确的关键字对 20 年后阅读您文档的人来说仍然是明确的（并且文档通常包含错误，主要是因为复制/粘贴）。
所以这里是：今天在哪里使用 Int32 而不是 int ？
当您生成数据大小合理（IO、网络、跨平台数据...）并且在未来某个时间点的代码时- 可能是几十年后 - 必须有人理解并移植您的代码。关键原因在于时代。 1000行代码，用int就可以了，100000行，已经不行了。这是一项难得的职责，只有少数人 必须做，而且该死的，他们有斗争，如果只有一些人能更明确一点，而不是依赖“按惯例”或“在 IDE 中看起来很漂亮，Int32 太丑了”或“它们是一样的，别打扰，写这两个数字并按住 shift 键是浪费时间”，或“int 是明确的”，或“那些不喜欢 int 的人只是 VB 的粉丝 - 去学习 C# 你是菜鸟”（是的，这就是这里几个 cmets 的基本含义）
不要将我所写的内容视为笼统的看法，也不要试图在所有情况下推广 Int32。我清楚地说明了具体情况（在我看来，这在其他答案中并不清楚），以倡导少数人因为写得花哨而被主管指责Int32，同时同一位主管不了解将 C DLL 重写为 C# 需要这么长时间。这是一个边缘案例，但至少对于阅读者而言，“Int32”在其生命中至少有一个目的。
可以通过将问题反过来来进一步讨论这一点：为什么不在未来的 C# 规范中去掉Int32、Int64 和所有其他变体？这意味着什么？