Go语言int类型那么多，到底该用int还是int64？

技术圈

发布于 2026-03-27 12:23:10

1040

在Go语言开发中，我们经常会遇到一个问题：整型类型那么多，int、int8、int16、int32、int64，还有对应的无符号版本，到底该怎么选？特别是int和int64，这两个是最常用的，很多开发者在选择时都会纠结。这篇文章就来说说我的看法。

Go语言的整型家族

首先，我们来盘点一下Go语言中所有的整型类型：

// 有符号整型
int8    // -128 到 127
int16   // -32768 到 32767
int32   // -2147483648 到 2147483647
int64   // -9223372036854775808 到 9223372036854775807

// 无符号整型
uint8   // 0 到 255
uint16// 0 到 65535
uint32// 0 到 4294967295
uint64// 0 到 18446744073709551615

// 平台相关类型
int     // 32位系统是int32，64位系统是int64
uint    // 32位系统是uint32，64位系统是uint64
uintptr// 用于存储指针的整数类型

这里最关键的就是int类型，它的大小是平台相关的：在32位系统上是4字节（int32），在64位系统上是8字节（int64）。而int64则是固定的8字节，无论在什么平台上都一样。

该用int还是int64？

很多开发者的纠结点在于：既然int在64位系统上就是int64，那我直接用int64不就行了？其实没那么简单，让我们来看看几个实用的选择原则。

原则1：一般业务场景，优先用int

如果你只是用来表示一些普通的数值，比如数组索引、循环计数器、订单数量等，直接用int就够了。

// 数组索引
for i := 0; i < 10; i++ {
    fmt.Println(i)
}

// 订单数量
orderCount := 100

为什么推荐用int？因为：

Go标准库中大量使用int作为返回值
int是平台最优的整型类型
代码更简洁，不需要考虑类型转换

举个例子，len()函数返回的就是int：

s := []string{"a", "b", "c"}
length := len(s) // 返回int类型
fmt.Println(length)

如果你强行用int64，反而会遇到类型不匹配的问题：

// ❌ 编译错误：类型不匹配
var length int64 = len(s)

// ✅ 需要显式转换
var length int64 = int64(len(s))

原则2：需要跨平台一致性，用int64

如果你的数据需要在不同平台之间传输、存储，或者需要确保数值范围不受平台影响，必须用int64。

典型场景包括：

数据库ID字段
时间戳
跨网络传输的数值
可能超过21亿的大数值

// 数据库主键ID，用int64更稳妥
type User struct {
    ID int64 `db:"id"`
    Name string
}

// 时间戳，通常用int64
timestamp := time.Now().Unix() // 返回int64

// 处理大数值
bigNumber := int64(9223372036854775807)

特别是涉及数据库交互时，大多数数据库的BIGINT类型对应Go的int64，用int64可以避免很多类型转换的麻烦。

原则3：明确数值范围时，用具体类型

如果你清楚知道数值的范围，选择最小够用的类型可以节省内存。虽然现代服务器内存很大，但在处理大量数据时，合理的类型选择还是能带来性能提升。

// 年龄，不会超过255，用uint8足够
type Person struct {
    Age uint8
}

// 分数，0-100，用uint8
score := uint8(95)

// 状态码，用int32
statusCode := int32(200)

不过需要注意，Go语言中进行算术运算时，小类型会被提升为int，所以过于追求小类型反而可能带来频繁的类型转换。

实践场景分析

这里通过几个实际场景来看看具体该怎么选。

场景1：Web后端API开发

在Web后端开发中，我们经常需要处理请求参数、返回JSON数据。这时候该怎么选？

// 推荐做法
type User struct {
    ID   int64  `json:"id"`   // 数据库ID用int64
    Age  int    `json:"age"`  // 年龄用int足够
    Score int   `json:"score"` // 分数用int
}

为什么ID用int64？因为：

数据库自增ID可能会超过21亿
前后端交互时，JavaScript的Number类型精度限制
跨平台传输需要一致性

场景2：算法和数据结构

在实现算法和数据结构时，通常直接用int：

// 二分查找
func binarySearch(arr []int, target int) int {
    left, right := 0, len(arr)-1
    for left <= right {
        mid := left + (right-left)/2
        if arr[mid] == target {
            return mid
        } elseif arr[mid] < target {
            left = mid + 1
        } else {
            right = mid - 1
        }
    }
    return-1
}

这里用int是最自然的，因为：

数组长度len()返回int
索引计算都是int
不需要考虑跨平台问题

场景3：高性能计算

在处理大数据、高性能计算时，类型选择会影响内存占用和性能：

// 处理大量数据时，选择合适的类型
type DataPoint struct {
    Timestamp int64 // 时间戳用int64
    Value     int32 // 数值范围明确用int32
    Flag      uint8 // 标志位用uint8
}

这样设计可以让每个DataPoint结构占用更少的内存，在处理上百万条数据时，内存节省会很明显。

常见坑点和注意事项

坑点1：类型转换溢出

当从大类型转换到小类型时，可能会发生溢出：

var big int64 = 1234567890123
var small int8 = int8(big) // 溢出！结果不可预期
fmt.Println(small) // 输出什么？不确定！

解决方法：转换前检查范围，或者使用math包中的函数。

坑点2：int在32位系统上的限制

虽然现在大多数服务器都是64位，但如果你写的代码可能在32位系统上运行，就要注意int的范围限制：

// 32位系统上，int最大是2147483647
var count int = 2147483647
count++ // 32位系统上会溢出！

解决方法：如果数值可能超过21亿，直接用int64。

坑点3：JSON序列化时的精度问题

当把int64序列化为JSON时，如果数值超过2^53 - 1（约9007万亿），JavaScript的Number类型可能无法精确表示：

// 这种情况JavaScript可能会丢失精度（数值超过9007万亿时）
type User struct {
    ID int64 `json:"id"`
}

// 解决方法：用string传输
type User struct {
    ID int64  `json:"-"`
    IDStr string `json:"id"`
}

选择推荐

场景	推荐类型	理由
数组索引、循环计数器	int	与标准库一致，简洁
普通业务数值（用户年龄、分数等）	int	范围足够，使用方便
数据库ID、主键	int64	跨平台一致，避免溢出
时间戳	int64	标准做法，范围足够
跨网络传输的数值	int64	确保一致性
可能超过21亿的数值	int64	避免溢出风险
明确范围且很小的数值（如年龄）	uint8/int8	节省内存（但不要过度优化）