Golang实现MongoDB分页技巧

在Go中使用MongoDB分页时，看似简单的Skip+Limit方案实则暗藏性能陷阱——随着偏移量增大，MongoDB需全量扫描并丢弃前N条文档，导致CPU、内存和网络开销线性飙升，万级数据跳转千页可能直接超时；相比之下，游标分页虽更高效，但依赖排序字段稳定、非空且单调递增，对业务逻辑提出更高要求；实际开发中应优先采用游标分页，严格监控慢查询（如executionTimeMillis > 200ms），避免大偏移分页，并在数据量极小时才谨慎使用Skip+Limit，真正把“第N页”的语义从用户体验层下沉到数据库层之前，先问自己：这个“页”是否经得起高并发与大数据量的考验。

Go 用 mongo-go-driver 做分页，Skip + Limit 不是不能用，但线上慎用

跳过大量文档的 Skip 在 MongoDB 里是性能黑洞——它得把前 N 条全扫描、解码、丢弃，CPU 和网络开销随偏移量线性增长。10 万条数据跳到第 1000 页？可能卡住几秒甚至超时。

真实场景中，除非数据量极小（Skip 做分页。

• Skip 的数值越大，查询越慢，且无法利用索引跳过已跳过的部分
• 即使加了 { created_at: -1 } 索引，Skip(50000) 仍要定位并跳过前 5 万个匹配项
• 分页接口被爬虫或前端误点“下一页到底”，容易触发高偏移量请求，拖垮整个集合

用游标分页（Cursor-based Pagination）替代 Skip，Go 里怎么写

核心思路：不记“第几页”，而记“从哪条继续”。每次请求带上上一页最后一条文档的排序字段值（比如 _id 或 updated_at），用 $lt/$gt 查询下一批。

假设按 created_at 降序分页，取 20 条：

filter := bson.M{"created_at": bson.M{"$lt": lastCreatedAt}}
opts := options.Find().SetSort(bson.D{{"created_at", -1}}).SetLimit(20)
cursor, _ := collection.Find(ctx, filter, opts)

关键点：

• 必须确保 created_at 字段有索引，否则 $lt 扫描照样慢
• 如果存在时间相同的数据，需追加唯一字段（如 _id）避免漏/重：{"created_at": {"$lt": t}, "_id": {"$lt": lastID}}
• 首次请求不带 lastCreatedAt，直接查最新 20 条；响应体里返回第 20 条的 created_at 和 _id 给前端下一页用

FindOptions 里 SetSkip 和 SetLimit 的实际行为差异

SetLimit(10) 是硬限制，最多返回 10 条；SetSkip(100) 是跳过前 100 条，但之后有多少条就返回多少条——如果只剩 3 条，结果就是 3 条，不是报错或补空。

常见误用：

• 以为 Skip(100) + Limit(10) 能稳定拿到第 101–110 条 → 实际上若第 101 条被删了，返回的就是第 102–111 条，页与页之间可能跳跃或重复
• 在聚合管道（Aggregate）里混用 $skip 和 $limit，但没注意阶段顺序：放在 $match 后面才有效，放前面等于白跳
• SetSkip 传负数或非整数会 panic，运行时错误，不是静默忽略

什么时候真得用 Skip？附一个安全兜底写法

只有两种情况可考虑：后台管理页需要跳转任意页码（比如“跳到第 87 页”），或数据总量确定且极少变动（如配置表，

若必须用，至少加层防护：

• 服务端硬限制最大 Skip 值，比如 if skip > 10000 { return errors.New("offset too large") }
• 配合 CountDocuments 预判总条数，若 skip >= total 直接返回空数组，避免无意义扫描
• 开启 MongoDB 的慢查询日志，监控 executionTimeMillis 超过 200ms 的 find 操作，及时发现分页滥用

游标分页不是银弹——它要求排序字段稳定、不可为空、最好单调；而 Skip 看似简单，实则暗藏性能断崖。选哪个，取决于你敢不敢让“第 N 页”这个概念，在数据库里真正成立。

到这里，我们也就讲完了《Golang实现MongoDB分页技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！