Buffalo 框架无内置分页能力，所谓“Buffalo 分页”实为开发者在 handler 层手动集成 LIMIT/OFFSET 或游标分页逻辑；pop.All() 全量加载易致 OOM，必须将分页下沉至数据库查询层，并确保排序字段有索引。
Buffalo 框架本身不提供内置分页能力，所谓“Buffalo 分页”实际是开发者在 Buffalo 的 Go 模板 + HTTP handler 层手动集成数据库分页逻辑，不存在 buffalo.Paginate 或类似原生 API。
为什么不能直接用 Buffalo 内置功能做大数据分页
Buffalo 是一个轻量级 Web 框架，定位是快速构建 CRUD 应用，其 render 和 pop（ORM 层）均未封装分页中间件或自动偏移/限制转换。你看到的分页效果，全是手写 SQL 或 ORM 查询 + 手动传参实现的。
- 没有
Pageable接口、无Page结构体，不像 Spring Data JPA 那样抽象 -
pop.Connection#All()会加载全部结果到内存，大数据量下直接 OOM - 模板中用
{{range .data}}渲染时，数据必须已按页切好，框架不帮你截断
正确做法：在 handler 中用 LIMIT/OFFSET 或游标分页
核心是把分页逻辑下沉到数据库查询层，避免全表扫描和内存堆积。推荐两种方式：
-
LIMIT/OFFSET 方式（适合中小数据量、页码靠前）：
q.Paginate(1, 20)这类写法并不存在；你得自己拼Limit(20).Offset(0)，且必须配合OrderById()等确定性排序，否则翻页错乱 -
游标分页（强烈推荐用于百万级以上）：用上一页最后一条记录的
id或created_at作为下一页起点，例如WHERE id > ? ORDER BY id ASC LIMIT 20；避免OFFSET越大越慢的问题 - 务必在
id或排序字段上建索引，否则ORDER BY + LIMIT仍会触发 filesort
常见错误：误用 pop.Query 的 All() + 内存切片
这是新手高频陷阱：先 q.All(&results) 查出全部数据，再用 results[page*size:(page+1)*size] 截取。后果很直接：
- 查 1000 万行 → 全部加载进 Go slice → 内存暴涨数 GB
- GC 压力陡增，HTTP handler 超时，服务假死
- PostgreSQL 报
ERROR: out of memory，MySQL 触发max_allowed_packet限制
只要数据量超过单机内存的 10%，就必须放弃这种写法。
模板里怎么安全传分页参数
Buffalo 模板不解析 URL 参数，你需要显式把分页上下文注入 render.Data：
func ListUsers(c buffalo.Context) error {
page := c.Param("page")
size := c.Param("size")
// …… 查询逻辑（用 LIMIT/OFFSET 或游标）
return c.Render(200, r.HTML("users/index.plush.html"), map[string]interface{}{
"users": users,
"page": page,
"size": size,
"hasNext": len(users) == size, // 简单判断是否有下一页
})
}
注意：hasNext 判断不能只看当前页长度（比如刚好 20 条），更稳妥的是查 SELECT COUNT(*) 或用游标是否能继续获取来推断 —— 后者性能更好，但需额外一次查询或带边界标识返回。
真正难的不是写几行分页代码，而是决定该用 OFFSET 还是游标、如何设计游标字段、要不要加缓存层、以及前端 URL 怎么跟后端语义对齐。这些决策点一旦定错，后期数据量翻倍时几乎无法平滑演进。
