Limit 和 Offset 是 GORM 分页唯一可靠方式，必须配合显式 Order（如 Order("id ASC")）保证顺序稳定，Count 需独立会话，参数须校验，超十万行应改用游标分页。
Limit 和 Offset 是 GORM 做员工档案分页唯一可靠的方式，别指望 Paginate 方法开箱即用——它不是 GORM 内置功能，所有“自动分页”封装都只是对这两个函数的包装，还可能引入兼容性或边界问题。
为什么不能跳过 Order 直接分页
员工档案表（比如 employees）常有并发增删：HR 批量导入、离职同步、状态变更。没 Order 的 Limit/Offset 查询在 MySQL 或 PostgreSQL 中不保证行序稳定，翻页时可能漏掉张三、重复出现李四。
必须显式加排序，且字段要带索引：
-
Order("id ASC")最稳妥，主键天然唯一、有索引 -
Order("updated_at DESC, id DESC")适合按修改时间倒序查看最新变动，二级id防止时间相同导致顺序漂移 - 避免只用
Order("name ASC")—— 名字重复率高，无索引时性能差，有索引也难保分页一致性
Count 查询必须和分页查询隔离会话
常见错误是写成：db.Where("status = ?", "active").Limit(pageSize).Offset(offset).Count(&total)。这查出来的是“当前页条数”，永远 ≤ pageSize，不是总人数。
正确做法是新建一个干净的 DB 实例做统计：
db.Session(&gorm.Session{NewDB: true}).Model(&Employee{}).Where("status = ?", "active").Count(&total)- 复杂关联场景（比如要查“部门+岗位+员工”三表 JOIN 后的总数），直接手写子查询更可控：
db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM employees e JOIN departments d ON e.dept_id = d.id WHERE e.status = ?) AS t", "active").Scan(&total)
参数校验不能依赖前端传值
HR 系统接口 URL 可能是 /api/employees?page=1&page_size=20&dept_id=5，但攻击者或前端 bug 可能传 page=-1、page_size=10000、甚至 page=abc。
- 用
c.ShouldBindQuery(&p)绑定结构体，比c.Query()更安全，能统一拦截非法类型 -
PageNum≤ 0 时强制设为 1；PageSize超出配置上限（如 100）就截断，别拒掉整个请求——HR 导出场景下，前端可能误设大页码，后端应降级处理而非报错 - 计算
offset前务必检查乘法溢出：if (page-1) > math.MaxInt64/int64(pageSize) { offset = 0 }，防止超大page导致负偏移 panic
员工数据量超 10 万时，Offset 就该停用了
当 employees 表突破十万行，OFFSET 50000 在 MySQL 上需扫描并丢弃前 5 万行，响应从 20ms 拉到 800ms+，且随页码线性恶化。
这时应切换游标分页，尤其适合 HR 系统的典型操作：
- 滚动加载员工列表：前端传上一页最后一条的
id和updated_at，后端查WHERE id > ? AND updated_at - 确保
(updated_at, id)有联合索引，避免回表 - 游标分页无法跳转任意页，但 HR 查档案本就以“浏览+筛选”为主，非强需求跳转第 200 页
真正容易被忽略的是：游标字段必须全局唯一且单调——用 updated_at 单独做游标，在毫秒级并发更新下会冲突；id + 时间戳组合才是生产可用的底线。
