Beego ORM分页需用Limit(limit, offset)组合，首参数为每页条数、次参数为偏移量；总数必须调Count()获取，不可用len()反推；须显式OrderBy保证顺序稳定，并校验page/limit为正整数防越界。
Beego 的 ORM 本身不提供内置分页函数，但通过 Limit + Offset 组合能稳定实现分页，关键在参数顺序和总数计算逻辑——错一位就漏数据或越界。
beego ORM 的 Limit 参数顺序容易搞反
Beego 的 Limit 是 Limit(limit, offset)，不是常见的 limit, offset 或 offset, limit。官方文档没强调这点，但源码和实测都确认：第一个参数是每页条数（pageSize），第二个才是起始偏移（(page - 1) * pageSize）。
- 写成
qs.Limit(10, 20)表示“取 10 条，从第 20 条开始”，即第 3 页（页码从 1 起） - 若误写为
qs.Limit(20, 10)，会取前 20 条、跳过 10 条，结果只有 10 条且内容错乱 - MySQL/PostgreSQL 底层生成的 SQL 是
LIMIT 10 OFFSET 20，符合标准
总数统计必须用 Count()，不能靠 len()
分页必须知道总记录数来算总页数、判断当前页是否越界。qs.Count() 是唯一可靠方式；len(resultSlice) 只反映本次查询拿到几条，对最后一页或空页完全失效。
-
Count()执行的是SELECT COUNT(*) FROM ...，开销小且准确 - 别在
All(&slice)后用len(slice)去反推总数——比如第 5 页请求 20 条，但实际只剩 3 条，len返回 3，不代表总数是 3 - 如果业务允许近似值（如百万级日志），可缓存总数或用估算（但 Beego ORM 不内置该能力）
分页时排序必须显式指定 OrderBy
不加 OrderBy 的分页在多数数据库中结果不稳定，尤其 PostgreSQL 和 MySQL 8.0+ 默认不保证无序查询的行序一致性。同一页刷新可能数据跳变。
- 哪怕只按主键排，也要写
qs.OrderBy("id")或qs.OrderBy("-created_at") - 复合排序如
qs.OrderBy("status", "-updated_at")需确保字段有索引，否则分页性能骤降 - 注意：Beego ORM 的
OrderBy不支持表达式，如"LOWER(name)"会报错，得改用原生 SQL
前端传参校验不能只靠 GetInt 默认值
用户 URL 里传 ?page=-100&limit=9999999 会导致 Offset 为负或超大，ORM 可能静默失败或查出意外数据。
- 用
GetInt获取后，必须手动检查范围：if page ，<code>if limit > 100 { limit = 100 } -
Offset理论上可为 0，但负值直接导致qs.Limit(n, -1)panic（Beego v2.0+ 会报invalid argument to Intn类错误） - 建议统一用正整数校验工具函数封装，避免每个控制器重复写
真正麻烦的不是写分页逻辑，而是当 Count() 和 Limit/Offset 查询跨了两次数据库往返，中间有数据增删时，总数和实际页内容可能不一致——这是所有无事务分页的共性问题，Beego ORM 也不例外。如果业务强一致要求高，得考虑游标分页（cursor-based pagination）或加读锁，但 Beego ORM 原生不支持游标模式。
