Go Web开发中应统一解析查询参数并封装分页响应。定义ListQuery结构体集中管理分页与过滤字段，用ShouldBindQuery自动校验；返回PageResult泛型结构，隐藏数据库细节，含数据、页码、总数、总页数及has_more标识。
在 Go Web 开发中，合理处理分页和查询参数是构建高性能、易用 API 的关键。核心在于：统一解析、安全校验、灵活组合、避免硬编码。
一、定义标准查询结构体，集中管理分页与过滤字段
不要在每个 handler 里重复写 page、limit、keyword 等参数解析逻辑。定义一个可复用的查询结构体，并内嵌分页基础字段：
type ListQuery struct {
Page int `form:"page" binding:"omitempty,min=1,default=1"`
Limit int `form:"limit" binding:"omitempty,min=1,max=100,default=20"`
// 可按需扩展业务字段
Keyword string `form:"keyword" binding:"max=50"`
Status string `form:"status" binding:"oneof=draft published archived"`
SortBy string `form:"sort_by" binding:"omitempty,oneof=id created_at updated_at"`
Order string `form:"order" binding:"omitempty,oneof=asc desc,default=desc"`
}
配合 Gin（或其他框架）使用 ShouldBindQuery 自动绑定并校验，异常直接返回 400。
二、封装分页响应结构，隐藏数据库细节
前端不需要知道 offset 或 total count 怎么算，只需清晰的“当前页数据 + 分页元信息”。推荐返回结构如下：
type PageResult[T any] struct {
Data []T `json:"data"`
Pagination struct {
Page int `json:"page"`
Limit int `json:"limit"`
Total int `json:"total"`
Pages int `json:"pages"`
HasMore bool `json:"has_more"`
} `json:"pagination"`
}
构造时用 math.Ceil(float64(total)/float64(limit)) 计算总页数，HasMore = page * limit 判断是否还有下一页。
三、数据库层解耦分页逻辑，支持多种驱动
避免 SQL 拼接或 ORM 特定分页方法（如 GORM 的 Limit/Offset）污染业务层。封装通用分页查询函数：
- 接收原始 SQL（或 *gorm.DB / *sqlx.DB）、参
数、page/limit - 自动计算 offset：
offset := (query.Page - 1) * query.Limit - 先查总数（用
SELECT COUNT(*)子查询或EXPLAIN优化），再查数据 - 对 PostgreSQL 可用
OFFSET ... LIMIT ...；MySQL 同理；SQLite 注意LIMIT offset, size语法差异
数、page/limit四、支持动态字段筛选与排序，但限制白名单
用户传 ?sort_by=name&order=asc 很常见，但不能直接拼进 SQL 防止注入。做法是：
- 定义允许排序的字段映射表：
validSortFields = map[string]string{"name": "users.name", "created_at": "users.created_at"} - 校验
query.SortBy是否在白名单中，否则忽略或报错 - 拼接 ORDER BY 时只取映射后的安全列名
- 同理，WHERE 条件中的字段（如 status、category）也应走预定义键值映射，不接受任意字段名
不复杂但容易忽略：所有外部输入都必须有默认值、范围限制和语义校验，分页不是加两个参数，而是整套请求-处理-响应契约的设计。
