iris mvc 不提供自动分页，需手动解析 url 中的 page 和 size 参数，校验范围并传入数据层执行 count 与 limit 查询。
分页不是 Iris MVC 自动提供的功能，必须手动解析参数、校验、传入数据层并返回元信息——框架只管路由和方法调用，不分页。
怎么从 URL 里安全读取 page 和 size 参数
不要依赖自动绑定，Iris MVC 不会把 page 或 size 当作方法参数注入。你得在 controller 方法里显式调用 c.URLParamInt：
- 用
c.URLParamInt("page")和c.URLParamInt("size")读取，它们返回(int, error) - 必须检查 error：参数缺失、非数字、溢出都会失败，不处理会 panic
- 强制约束范围：
page >= 1，size > 0 && size （防恶意拉取） - 别用
c.FormValue或c.QueryValue替代——它们返回 string，容易漏掉类型转换错误
怎么把分页参数传给数据库查询
控制器只负责“转交”，真正分页逻辑在 service 或 repository 层。关键不是写法，而是避免常见错位：
- Offset 计算必须是
(page - 1) * size，不是page * size——否则第一页就跳过前size条 - 用 GORM：写成
.Offset((page - 1) * size).Limit(size)，别拼 SQL 字符串 - 用
database/sql：用query := "SELECT ... LIMIT ? OFFSET ?"，再按size、offset顺序传参 - 绝对不要写
"LIMIT " + strconv.Itoa(size)—— 这绕过参数化，有 SQL 注入风险
为什么前端总是显示“共 0 条”或页码错乱
问题几乎总出在漏掉 COUNT 查询，而不是 limit 查询本身：
- 必须执行一次与主查询条件完全一致的
SELECT COUNT(*)，不能用len(data)代替total - 如果主查询带
WHERE status = ? AND created_at > ?，count 查询也得一模一样 - count 查询性能比 limit 查询差得多，尤其带 JOIN 或全文检索时——上线前务必压测真实数据量下的耗时
- 响应结构建议固定为：
{"data": [...], "total": 127, "page": 2, "size": 10}，避免前端反复适配
最容易被忽略的是：Iris MVC 的 controller 方法没有“隐式事务”或“隐式分页上下文”，所有参数校验、SQL 构造、count 与 data 查询的同步性，都得你一行行写清楚。少一个 if page ，就可能让数据库被拖垮。
