17370845950

Go分页核心是slice视图切分而非传指针，因slice本身含指向底层数组的ptr字段，值传递即可零拷贝；需校验索引防panic，结合数据库游标分页与预分配slice提升性能。

Go语言中分页查询的核心在于：用指针避免数据拷贝，用slice切片精准截取数据段。关键不是“传递指针”，而是“对底层数组的同一份数据做视图切分”，配合合理的索引计算，就能高效完成分页。

理解slice底层结构——为什么分页不需传指针

slice本身是轻量结构体（含ptr、len、cap三个字段），值传递开销极小。所谓“用指针”，通常是指函数接收*[]T（指向slice的指针），但这仅在需要修改slice头信息（如追加后让调用方看到新len/cap）时才必要。分页只需读取数据，直接传[]T即可，无需额外指针。

• slice的ptr字段已是指向底层数组的指针，分页切片（如 data[off:off+size]）复用同一底层数组，零拷贝
• 传*[]T反而增加间接访问，且易引发误操作（如意外重置整个slice）
• 真正该用指针的场景：函数内需append并希望调用方获得扩容后的新slice头

安全分页切片——避免panic的关键检查

直接用data[page*size : min((page+1)*size, len(data))]看似简洁，但忽略边界易panic。必须显式校验索引合法性：

• 起始偏移 offset = page * size 不能超过 len(data)
• 结束位置 end = offset + size 需与 len(data) 取最小值
• 若 offset >= len(data)，返回空slice（而非panic），表示无数据

示例函数：

func PageSlice[T any](data []T, page, size int) []T {
    if size <= 0 || page < 0 {
        return nil
    }
    offset := page * size
    if offset >= len(data) {
        return []T{}
    }
    end := offset + size
    if end > len(data) {
        end = len(data)
    }
    return data[offset:end]
}

结合数据库查询——减少内存压力的流式分页

对海量数据，不应先查全量再切片。应让数据库承担分页逻辑：

• SQL用 LIMIT size OFFSET offset（注意OFFSET大时性能下降）
• 更优方案：使用游标分页（cursor-based pagination），基于上一页最后一条记录的ID/时间戳查询下一页
• Go层只需处理查询结果的slice，例如：rows.Scan(&item.ID, &item.Name) 直接填入预分配的[]Item

此时“指针”体现在：将结果slice地址传给Scan（如&items[0]），让数据库驱动直接写入底层数组，避免中间拷贝。

高性能技巧——预分配与复用slice

频繁分页时，反复make新slice会触发GC。可复用底层数组：

• 初始化一个足够大的底层数组（如缓存池），所有分页slice都从中切出
• 用make([]T, 0, cap)创建零长但有容量的slice，后续append不触发扩容
• 对只读分页场景，用unsafe.Slice（Go 1.17+）绕过边界检查（需确保索引绝对安全）

例如预分配1000项缓冲区，每次分页取其中一段，生命周期结束后整体归还池中。