Beego中paginator需手动传入page和pageSize并校验，先查COUNT(*)再分页查询，模板中需正确传入并处理URL参数与边界情况。
Beego 中 paginator 的正确初始化方式
Beego 自带的 paginator 并非开箱即用，它不自动从 URL 解析页码或每页条数，必须手动传入当前页（page）和每页数量（pageSize），再配合总记录数才能构建分页对象。
常见错误是直接调用 paginator.NewPaginator 却没校验 page 是否为正整数，导致分页跳转 404 或数据错乱。
-
page应从this.Ctx.Input.Param(":page")或this.GetString("p")获取，并用strconv.Atoi转换后做max(1, page)处理 -
pageSize建议设上限（如 50），防止恶意传入超大值拖垮数据库查询 - 总记录数必须先查一次
COUNT(*)，不能依赖查询结果长度——因为可能被LIMIT截断
结合 ORM 查询实现带分页的列表接口
Beego 的 orm.QuerySeter 不内置 OFFSET/LIMIT 分页逻辑，需手动拼接。错误做法是先查全部再内存切片，大数据量下直接 OOM。
正确流程是：先查总数 → 计算偏移量 → 再查数据子集。
- 偏移量 =
(page - 1) * pageSize，注意page从 1 开始，不是 0 - 使用
qs.Limit(pageSize, offset)，其中offset是第二个参数，顺序不能反 - 若用原生 SQL，确保
ORDER BY存在，否则分页结果不稳定（尤其 MySQL 5.7+ 默认无序）
示例片段：
total, _ := o.QueryTable("user").Count()
paginator := paginator.NewPaginator(this.Ctx.Request, pageSize, total)
offset := (paginator.PageIndex - 1) * pageSize
var users []User
o.QueryTable("user").OrderBy("-id").Limit(pageSize, offset).All(&users)
模板中渲染分页 HTML 的关键点
Beego 模板里不能直接用 .Paginator 对象调方法，必须提前在控制器中将 paginator 作为数据传入，且字段名要匹配模板引用。
容易忽略的是 URL 生成逻辑：分页链接需保留原有查询参数（如搜索关键词 q=go），否则翻页后搜索失效。
- 用
paginator.URLFor("Controller.Method", ":page", "2")生成链接，但该方法默认只替换路径参数，不保留 query string - 更稳妥的做法是手动拼：
this.Ctx.Request.URL.Path + "?p=" + strconv.Itoa(p) + "&q=" + this.GetString("q") - 前端展示时，检查
paginator.PageNums是否为空，避免空数组 panic；用range $i, $p := .Paginator.PageNums迭代页码
性能与边界情况处理
当总记录数极大（千万级）时，COUNT(*) 本身会变慢，这时 paginator 的总数显示反而成了性能瓶颈，需考虑是否真有必要精确显示“共 N 条”。
另外，Beego 1.x 的 paginator 在页码超出范围时不会自动修正，比如请求第 1000 页但总共只有 200 页，它仍会渲染出 1000 页链接，点击后查不到数据。
- 应在查询前判断：
if offset >= total { this.Data["users"] = []User{} } - 对高频分页接口，可缓存总记录数（如 Redis + 过期时间），但要注意数据变更时及时清理
- 移动端建议默认用“加载更多”代替页码跳转，减少 URL 参数复杂度
分页真正的麻烦不在代码几行，而在如何让总数查询不拖慢接口、URL 参数不丢失、页码越界不报错——这些细节漏掉一个，线上就容易出问题。
