安全提取分页参数需校验并设默认值：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
}别用 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 < ? ORDER BY id DESC LIMIT ?这里
? 是上一页最后一条的 id，不是页码。如果必须用页码（比如管理后台），至少加 WHERE created_at >= ? 缩小扫描范围，并确保 created_at 有索引。GORM 用户注意：Offset() 会生成 OFFSET，别无脑链式调用；原生 SQL 或 Session(&gorm.Session{SkipHooks: true}) 更可控。
怎么把分页结果和元信息一起返回给前端
前端需要总数、当前页、总页数、是否有下一页等，但别在一次查询里 COUNT(*) + SELECT —— 除非加缓存。更实用的做法是：查一页数据后，再查一次带 COUNT(*) 的子查询（小表可接受），或用 SQL_CALC_FOUND_ROWS（MySQL 8.0 已弃用，慎用）。推荐结构体封装：
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,
}HasNext 不能只靠 page < total_pages，因为 total_pages 是基于总数算的，而总数可能已变；用「本次是否查满一页」更准。
为什么 GIN/Echo 的中间件不适合做通用分页逻辑
有人想写个 Paginate() 中间件自动解析参数、注入 limit/offset 到 c.Set()，但问题明显：
- 不同 handler 的分页字段名可能不同（
pagevscurrentvsp） - 数据库查询逻辑千差万别（JOIN 多表时 count 很难复用）
- 中间件无法知道你最终要查多少字段、是否需要关联预加载
