iris框架不内置分页逻辑，需手动从url获取并校验page和size参数：用c.urlparamint读取，检查错误并确保page≥1、size在合理范围。
Iris 框架本身不内置分页逻辑，分页必须由你控制 SQL 查询或数据切片完成。它只负责接收参数、调用业务层、返回响应——分页是数据层或服务层的事，不是路由框架该干的。
如何从 URL 获取分页参数并校验
用户通常传 page 和 size（或 limit/offset），但 Iris 不自动解析或校验它们。你得手动取、转、防错：
- 用
c.URLParamInt("page")和c.URLParamInt("size")读取并转整型，失败会返回 error - 必须检查
page 或 <code>size 100，否则可能 panic 或拖垮数据库 - 别直接拼 SQL，尤其当参数来自
c.URLParam—— 即使转了 int，也要确保后续查询用参数化方式（如sqlx或gorm的Limit/Offset）
在数据库查询中正确应用 Limit/Offset
分页本质是 OFFSET (page-1)*size LIMIT size，但不同 ORM 写法差异大：
- 用
gorm：写成.Offset((page - 1) * size).Limit(size)，注意page最小为 1 - 用原生
database/sql：构造SELECT ... LIMIT ? OFFSET ?，按顺序传size和(page-1)*size - 避免手写
"LIMIT " + strconv.Itoa(size) + " OFFSET " + strconv.Itoa(offset)—— 容易被注入，且类型不安全
返回分页元信息时别漏掉 total count
前端需要知道总条数才能算页码。很多人只查数据，忘了查 COUNT(*)：
- 必须执行一次 count 查询（如
SELECT COUNT(*) FROM users WHERE ...），和主查询条件完全一致 - 不要用
len(data)当 total —— 那只是当前页数量，不是全量 - 响应结构建议统一：{
"data": [...],"total": 127,"page": 2,"size": 10} - 如果 count 查询代价高（比如带复杂 join 或全文检索），考虑加缓存或用近似值（如 MySQL 的
EXPLAIN行数估算），但得注明“非精确”
最常被忽略的一点：分页接口的性能瓶颈几乎总在 count 查询上，而不是 limit 查询。上线前务必用真实数据量压测 count 耗时。
