cursornotfound 错误本质是游标超时被服务端清理，mongodb 默认10分钟空闲即销毁游标，而pymongo.cursor惰性迭代需按需getmore；若间隔超时或客户端停顿，便触发该错误。
CursorNotFound 错误本质是游标超时被服务端清理
MongoDB 默认游标空闲 10 分钟就会自动销毁，而 Python 的 pymongo.cursor.Cursor 是惰性迭代器——它不一次性拉取全部数据，而是按需向服务端发 getMore 请求。一旦两次请求间隔超过服务端游标超时时间（或客户端因处理慢、网络卡顿、断点调试等导致停顿），再发 getMore 就会收到 CursorNotFound 错误。
no_cursor_timeout=True 并非万能，慎用
在 find() 时传 no_cursor_timeout=True 确实能禁用服务端超时，但代价明显：
- 服务端长期持有游标资源，占用内存和连接数，尤其在高并发或大数据量场景下易引发
too many open cursors - 如果客户端异常退出（如崩溃、kill -9），服务端不会自动回收该游标，需手动
db.killCursors()或等待后台清理（可能数小时） - 部分 MongoDB 云服务（如 Atlas 免费层、某些托管集群）会强制忽略该参数，仍按策略清理游标
只建议在明确可控、短时、低并发的运维脚本中临时启用，生产环境避免长期开启。
更稳妥的做法：分批读取 + 显式控制游标生命周期
核心思路是不让单个游标存活过久，主动拆分查询，每次只处理一批数据，并确保每批都在超时窗口内完成：
- 用
skip()+limit()分页（适合小数据集，skip大偏移量性能差） - 用范围查询分片（推荐）：基于有序字段（如
_id、created_at）做增量扫描，例如{'_id': {'$gt': last_id}}，每次取limit=1000，处理完更新last_id - 使用
batch_size参数控制每次从服务端预取文档数，减少网络往返次数（不影响游标超时，但可降低延迟风险） - 关键：所有数据库操作尽量放在
for doc in cursor:循环体内，避免在循环外做耗时操作（如写文件、调外部 API），否则极易触发超时
示例片段：
cursor = collection.find({'status': 'pending'}, no_cursor_timeout=False).sort('_id').batch_size(500)
last_id = None
while True:
batch = list(cursor.limit(500))
if not batch:
break
for doc in batch:
# 快速处理单条
process(doc)
last_id = doc['_id']
# 下次从 last_id 之后继续
cursor = collection.find({'_id': {'$gt': last_id}, 'status': 'pending'}, sort=[('_id', 1)])
其他容易被忽略的触发点
除了超时，以下情况也会导致 CursorNotFound，但错误信息完全一样：
- 副本集主节点切换后，原游标在新主上不可用（需重连并重建查询）
- 执行
collection.drop()或db.dropDatabase()后，关联游标立即失效 - 使用了
explain()或某些聚合管道阶段（如$out）后，返回结果不是常规游标 - PyMongo 版本过低（
遇到问题先确认是否真由超时引起——抓包看 getMore 请求是否在 10 分钟后才发出，或者加日志记录每次迭代的时间戳。盲目加 no_cursor_timeout 可能掩盖真实瓶颈。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
