First和Take不能用于分页，因二者不支持Offset且结果不可预测；正确做法是用Limit+Offset或游标分页（如WHERE created_at
First 和 Take 都不适合直接用于分页逻辑，强行套用会导致数据错乱或性能陷阱。 它们本质是单条记录检索方法，不是分页原语；所谓“妙用”其实是误读，真正该用的是
Limit+Offset或Page插件配合游标式查询。First 在分页场景下为什么不能当 “第一页第一条” 用
因为
First固定加ORDER BY id ASC，它不关心你当前在第几页，只认主键最小的那条。如果你的分页条件是WHERE status = 'active'，db.Where("status = ?", "active").First(&u)拿到的永远是满足条件中id最小的那条——和“第一页”无关，除非你恰好按id分页且没其他过滤条件。
- 它不接受
Offset，没法跳过前 N 条- 即使你链式写
.Offset(10).First()，GORM 会忽略Offset（文档明确说明First/Take/Last不支持Offset）- 在复合索引缺失时，
ORDER BY id可能触发全表扫描，而你本意只是取第一页的首条Take 看似“随便一条”，但在分页里更危险
Take的 SQL 就是SELECT ... LIMIT 1，无序、不可预测。用它模拟“取某页任意一条”等于放弃一致性：同一查询执行两次可能返回不同记录，前端刷新后列表首项突变，用户感知为 bug。
- 它不保证可重复读，也不适合作为分页锚点（比如用上一页最后一条的
id做下一页WHERE id > ?）- 搭配
Where使用时，结果完全取决于数据库引擎返回结果集的自然顺序（可能是插入顺序、文件物理顺序等），MySQL 8.0+ 甚至可能每次不同- 想靠
Take实现“检查是否存在”可以，但一旦涉及分页上下文，它就失去意义真正适合分页的替代方案
分页要的是可控、可预测、可延续的结果集切片，不是单条记录的捷径。
- 传统偏移分页：用
Limit(10).Offset(20)，注意Offset越大性能越差，适合数据量小或深度分页不频繁的场景- 游标分页（推荐）：查第一页时
ORDER BY created_at DESC, id DESC LIMIT 10，后续请求带WHERE created_at ，避免OFFSET跳跃开销- 如果坚持用
First类语义，只能把它当作“获取某页首条”的后处理步骤：先Limit(1).Offset(n*limit)查出结果集（哪怕只取一条），再用First赋值——但这纯属冗余，直接Limit(1).Offset(...).Find(&u)更直白最易被忽略的一点：
First和Take的行为依赖 model 是否定义主键。没主键时，GORM 会按 struct 第一个字段排序（First）或不排序（Take），这种隐式 fallback 在分页上下文中几乎必然导致线上问题——而日志里不会报错，只会静默返回错数据。
深入解析GORM框架中First与Take方法在分页中的妙用
秋丽吖_5421
2026-09-10
634人浏览
原创
