paginate不是gorm内置方法，所有实现均来自第三方插件，存在版本兼容风险、参数校验缺失、count查询污染、无强制order导致数据重复/丢失等问题；企业级绩效系统必须手写limit+offset分页并严格校验参数、隔离count查询、显式order排序，高偏移场景应切游标分页。
Paginate 不是 GORM 内置方法，企业级员工绩效系统里硬套它，上线后大概率出问题。
为什么不能直接用 Paginate 方法
GORM 官方从未提供 Paginate 函数——所有叫这个名字的实现都来自第三方插件（比如 github.com/joshbetz/pagination）。这些插件在 GORM v2.6+ 中因 Scope 行为变更已出现静默漏数据、page=0 不校验、pageSize=0 返回全表（SQLite 下）等问题。
- 插件不隔离
Count查询，复用同一*gorm.DB实例会导致总数查成 limit 后的数量 - 它不强制加
Order，而绩效数据若没显式排序（如Order("updated_at DESC, id DESC")），翻页时同一条记录可能重复出现或突然消失 - 升级 GORM 小版本后，插件可能完全失效，但编译不报错，问题只在压测或高峰时暴露
Limit + Offset 分页必须做的三件事
手写分页不是“多写两行”，而是守住三条底线：
-
page必须 ≥ 1，pageSize必须 ∈ (0, 100]：用strconv.Atoi前先判空；超出 100 的pageSize可能被恶意利用拖垮数据库 -
Offset((page - 1) * pageSize)和Limit(pageSize)必须配对出现，且Order要写在它们之前（顺序影响可读性，也防某些驱动解析歧义） - 总数查询必须另起一个干净的
*gorm.DB实例：用db.Session(&gorm.Session{NewDB: true})或直接从全局DB重新开始链式调用，否则Count会继承前面的Where和Limit
绩效数据高偏移场景必须切游标分页
当员工数超 5 万、绩效记录按月归档、或支持“无限滚动”查看历史考核时，Offset(50000).Limit(20) 在 MySQL/PostgreSQL 中实际要扫描并丢弃前 5 万行——响应时间从 20ms 涨到 2s+ 是常态。
- 游标分页依赖确定性排序字段：首选带索引的自增
id，次选created_at+id组合（避免时间重复） - 首次请求：用
Order("id ASC").Limit(20)；后续请求传上一页最后一条的last_id，查WHERE id > ? ORDER BY id LIMIT 20 - 别在游标分页里用
Preload("Reviews")：先查出本页员工id列表，再用IN批量加载关联绩效详情，否则会放大 N 倍查询压力
容易被忽略的 Count 查询细节
绩效系统常需返回总页数，但多数人写的 Count 是错的：
- 错误写法：
db.Where("dept_id = ?", deptID).Limit(20).Offset(0).Count(&total)→ 返回的是最多 20 条，不是真实总数 - 正确写法：
db.Session(&gorm.Session{NewDB: true}).Model(&Performance{}).Where("dept_id = ?", deptID).Count(&total) - 如果绩效表有软删除（
deleted_at），Count必须显式加Unscoped()或排除条件，否则总数少于预期
性能拐点往往不在代码逻辑，而在没意识到 Count 复用了带 Limit 的 DB 实例，或者以为 Paginate 是安全黑盒。真实业务里，一次错误的总数查询可能让报表接口平均延迟翻倍。
