我理解int和uint是64位有符号/无符号整数-就像int64/uint64一样。我也明白，int不仅仅是int64的别名(如byte -> uint8)，因此int64需要转换为int，反之亦然。然而，使用其中一个比另一个有什么好处呢?使用一般类型是否有任何运行时性能损失?
对不起，如果这是一个常见的问题-我已经谷歌的答案(和搜索在这里也是)，因为我认为其他人可能已经出现之前，但没有找到任何人回答的问题，他们如何影响性能(如果有的话)，内存使用(我猜不是如果他们都是64位整数?)，也没有编译器如何对待他们。
我知道int/unit在32位架构上是32位的。为了简洁和比较，我假设这是一个64位的Golang环境。
int和uint仅在64位架构上是64位。在32位体系结构中，它们是32位的。
int和uint对应于Go实现和运行时中基本Go数据结构的最大可能长度。string、map[K]T、[]T和chan T的长度总是适合int, []T和chan T的容量总是适合int。
通过make进行分配必然返回一个长度和容量总是适合int的对象。内置函数append返回一个长度和容量都不超过int的切片。在插入新的键-值对后，映射的长度(定义的键的数量)总是符合int。
主要的好处是 int和uint是最小的(就位大小而言)数据类型，可以安全地在Go程序中与常见的Go数据类型(如切片和映射)一起使用。
int的大小与指针*T的大小无关。"*T"对应的整数类型为"uintptr"。理论上，一个围棋实现可以选择将int映射到int16——许多围棋程序仍然可以正常工作，但是将分配的大小限制为15位可能过于严格，并且会导致运行时恐慌。
在64位架构上Go 1.0有int和uint 32位长，Go 1.1有64位长(参见Go 1.1发布说明)。.
在Go 1.0和32位架构下显式使用int64而不是int会使Go程序变慢，因为:
-
int和int64之间的转换 -
某些CPU指令的性能，例如除法，取决于操作数的大小
在64位架构的Go 1.0下，显式地使用int64而不是int可以使Go程序更快，因为:
- 如果所有操作数都是64位，编译器可以生成更有效的地址和偏移量计算代码。当计算地址和偏移量时，混合32位和64位操作数会更慢。
在访问[1<<16]T时使用uint16作为索引允许编译器删除绑定检查指令。
除了int是"本机"大小之外，切片和数组的下标是int而不是int64或int32。