Skip+Limit分页在MongoDB中性能差，因需扫描丢弃前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 条：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
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 页”这个概念，在数据库里真正成立。
