分页逻辑应放在Model或Service层，Controller仅负责解析校验page/perPage参数并调用；Model需执行物理分页（LIMIT/OFFSET）与总数查询（推荐窗口函数），避免内存溢出和N+1问题。
Revel 框架里分页逻辑该放在 Controller 还是 Model？
分页不是 UI 层的事，也不是单纯前端传个 page 和 limit 就能跑通的。Revel 的典型结构里，分页计算和数据裁剪必须在 Model 或 Service 层完成，Controller 只负责接收参数、调用、组装结果。否则容易出现内存溢出（比如全量查 10 万条再切片）或 SQL 性能灾难。
-
Page和PerPage参数应由 Controller 解析并校验（如page <= 0则设为 1，PerPage > 100则截断为 100） - Model 层需接收这两个值，并在 SQL 中用
LIMIT+OFFSET（MySQL/PostgreSQL）或OFFSET … FETCH NEXT（SQL Server）做物理分页 - 不要依赖 Go 的
slice[start:end]做逻辑分页——它会先加载全部结果到内存
怎么写一个可复用的分页查询函数（带总数）？
Revel 没内置分页助手，得自己封装。核心是：一次查询拿到总数 + 分页数据，避免 N+1 查询。常见错误是先 SELECT COUNT(*) 再 SELECT ... LIMIT，但并发高时总数可能和实际返回不一致；更稳妥的是用子查询或窗口函数（PostgreSQL 推荐）。
以 PostgreSQL 为例，推荐这样写：
SELECT *, COUNT(*) OVER() AS total_count FROM users WHERE status = $1 ORDER BY id DESC LIMIT $2 OFFSET $3
-
$1,$2,$3分别对应status,per_page,(page-1)*per_page - 返回结果中每行都带
total_count字段，取第一行即可得总数 - Go 结构体需包含
TotalCount int64 <code>db:"total_count"字段来接收
如果用 MySQL，只能分两步查（5.7+ 支持 SQL_CALC_FOUND_ROWS，但已弃用），所以老实用两个 query：
SELECT COUNT(*) FROM users WHERE status = ? SELECT * FROM users WHERE status = ? ORDER BY id DESC LIMIT ? OFFSET ?
Revel Controller 怎么安全传递分页参数并渲染？
Controller 不该直接把 page 当整数用：c.Params.Get("page") 返回的是字符串，没校验就转 int 会 panic。正确做法是：
- 用
revel.Params.Int（自动处理空值和非法输入，失败时返回 0） - 显式设置默认值：
page := c.Params.Int("page", 1) - 校验范围：
if page < 1 { page = 1 } - 把
page、per_page、total、data一起塞进c.RenderArgs传给模板
模板里不要手写 <a href="?page=2">，用 Revel 的 url 函数生成带当前筛选条件的链接：
{{url "App.Users" "page" 2}}但注意：如果 URL 已有其他 query 参数（如 ?q=go&page=1），url 函数不会自动保留它们——得手动拼或改用 c.Request.URL.Query() 在 Controller 中构造完整参数 map。
为什么用 Revel 自带 ORM（Gorm）做分页容易翻车？
Revel 官方示例常用 revel/db/gorm，但它对分页支持很弱：
-
Limit().Offset()能分页，但 不提供总数，必须额外Count() -
Count()会忽略Where条件里的关联字段（比如joins("Profile").Where("profile.age > ?", 18)），导致总数不准 - 多次
Count()+Find()会执行两次全表扫描（无索引时极慢）
建议绕过 Gorm 的链式分页，直接用原生 SQL 或 Session.Raw()：
var users []User var total int64 err := db.Raw(` SELECT *, COUNT(*) OVER() AS total_count FROM users WHERE deleted_at IS NULL ORDER BY created_at DESC LIMIT ? OFFSET ?`, perPage, (page-1)*perPage).Scan(&users).Error // 然后从 users[0].TotalCount 取总数（需 User 结构体含 TotalCount 字段）
分页本身不难，难的是总数一致性、参数校验边界、ORM 封装陷阱——这些地方一松懈，上线后就是慢查询告警和用户点下一页白屏。
