Golang实现Web分页查询技巧

一分耕耘，一分收获！既然打开了这篇文章《Golang实现Web分页查询方法》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

安全提取分页参数需校验并设默认值：page默认1、size默认20且上限100；数据库应避免OFFSET深翻页，改用游标分页；响应结构体封装元信息，HasNext依实际查满判断；分页逻辑不宜放中间件，宜抽象为纯函数。

分页参数怎么从 HTTP 请求里安全提取

用户传的 page 和 size 必须校验，否则直接进 SQL 或内存切片会 panic 或查出意外数据。Go 的 net/http 默认不解析 query 参数为整数，得手动转：

page := r.URL.Query().Get("page")
size := r.URL.Query().Get("size")
<p>// 转换并设默认值
pageNum, err := strconv.Atoi(page)
if err != nil || pageNum < 1 {
pageNum = 1
}
sizeNum, err := strconv.Atoi(size)
if err != nil || sizeNum < 1 || sizeNum > 100 { // 硬限制防 DOS
sizeNum = 20
}</p>

别用 http.ParseForm() 再取，r.URL.Query() 更轻量、更明确。注意：strconv.Atoi 对空字符串返回 error，所以要先判空或用 url.Values.Get（它对不存在 key 返回空字符串）。

数据库层分页怎么写才不踩 offset 深度翻页坑

用 LIMIT OFFSET 在 MySQL/PostgreSQL 里查第 10000 页时性能断崖下跌。真实项目该用游标分页（cursor-based），尤其配合时间戳或自增 ID：

SELECT * FROM posts 
WHERE id 这里 <code>?</code> 是上一页最后一条的 <code>id</code>，不是页码。如果必须用页码（比如管理后台），至少加 <code>WHERE created_at >= ?</code> 缩小扫描范围，并确保 <code>created_at</code> 有索引。GORM 用户注意：<code>Offset()</code> 会生成 <code>OFFSET</code>，别无脑链式调用；原生 SQL 或 <code>Session(&gorm.Session{SkipHooks: true})</code> 更可控。<h3>怎么把分页结果和元信息一起返回给前端</h3><p>前端需要总数、当前页、总页数、是否有下一页等，但别在一次查询里 <code>COUNT(*)</code> + <code>SELECT</code> —— 除非加缓存。更实用的做法是：查一页数据后，再查一次带 <code>COUNT(*)</code> 的子查询（小表可接受），或用 <code>SQL_CALC_FOUND_ROWS</code>（MySQL 8.0 已弃用，慎用）。推荐结构体封装：</p><pre class="brush:php;toolbar:false">type PageResult[T any] struct {
    Data       []T `json:"data"`
    Total      int `json:"total"`
    Page       int `json:"page"`
    PageSize   int `json:"page_size"`
    TotalPages int `json:"total_pages"`
    HasNext    bool `json:"has_next"`
    HasPrev    bool `json:"has_prev"`
}
<p>// 构造时显式计算
res := PageResult[User]{
Data:       users,
Total:      total,
Page:       pageNum,
PageSize:   sizeNum,
TotalPages: int(math.Ceil(float64(total) / float64(sizeNum))),
HasNext:    len(users) == sizeNum, // 实际查到满额，才可能有下一页
HasPrev:    pageNum > 1,
}</p>

HasNext 不能只靠 page < total_pages，因为 total_pages 是基于总数算的，而总数可能已变；用「本次是否查满一页」更准。

为什么 GIN/Echo 的中间件不适合做通用分页逻辑

有人想写个 Paginate() 中间件自动解析参数、注入 limit/offset 到 c.Set()，但问题明显：

• 不同 handler 的分页字段名可能不同（page vs current vs p）
• 数据库查询逻辑千差万别（JOIN 多表时 count 很难复用）
• 中间件无法知道你最终要查多少字段、是否需要关联预加载

真正该抽象的是「分页参数解析函数」和「分页响应构造函数」，它们是纯逻辑，不耦合路由或 DB 层。把分页塞进中间件，等于把业务规则提前到请求入口，后续反而更难调试和测试。

今天关于《Golang实现Web分页查询技巧》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！