惰性加载游标可将内存占用压至常量级：通过封装为生成器、stream或迭代器实现按需拉取，避免全量加载；需警惕伪惰性操作，并显式控制fetch size与复用对象以进一步控压。
处理数据库游标（如 PL/SQL 中的 REF CURSOR、JDBC 的 ResultSet 或 Django/ORM 的 QuerySet）时，若一次性拉取全部结果到内存，极易引发 OOM 或 GC 压力。而“集合流的惰性加载”本质是将游标封装为可迭代的流式结构，在每次消费时才从数据库驱动中 fetch 下一批数据，不缓存未访问项，从而把内存占用压到常量级。
游标本身已是天然流，关键在如何接入应用层流式语义
多数数据库驱动（如 psycopg2、cx_Oracle、SQL Server 的 SqlDataReader）默认支持逐行或分块 fetch，但框架常将其自动转为 list 或 dict 集合。要启用惰性，需绕过中间聚合，直接暴露迭代器接口：
- Python 中用 yield 封装 fetchone/fetchmany：返回生成器，调用方 for 循环即可流式消费；
- Java 中将 ResultSet 包装为 Stream，配合 Spliterator 实现按需拉取；
- Django ORM 中避免
.list()或list(queryset)，改用for obj in queryset:—— 此时 QuerySet 按chunk_size=2000分页 fetch，不全量加载； - Laravel Eloquent 中使用
cursorPaginate()替代paginate()，基于游标而非 offset，避免深分页性能衰减和内存堆积。
警惕“伪惰性”：缓存、求值时机与副作用
有些看似流式的行为实则已触发全量加载：
- 调用
len()、list()、json.dumps()等会强制求值，清空游标并缓存全部结果； - ORM 中链式调用
.filter().order_by().values()仍属惰性，但一旦接.first()或.count()，就可能执行额外 SQL 或加载全部； - 某些驱动（如旧版 MySQLdb）在 fetch 前会预读全部结果进内存，需确认是否启用
sscursor=True（服务器端游标）或stream_results=True。
结合内存池与分块处理进一步控压
即使流式迭代，单次 fetch 的 batch size 过大仍会撑高峰值内存。建议显式控制分块粒度，并复用对象容器：
- 设置 fetch size（如 JDBC 的
setFetchSize(100)，psycopg2 的itersize=500）； - 对每批结果做即时转换或写入下游（如批量插入另一库、写文件、发消息），避免累积；
- 在循环内复用临时 map/list 实例（如 Java 中 clear 后重用 ArrayList），减少 GC 频率；
- 必要时搭配对象池（如 Apache Commons Pool）管理频繁创建的 DTO 实例。
真正发挥游标流价值，不在于“能不能遍历”，而在于“遍历时不驻留、不复制、不预占”。把数据库当源头流，而非数据快照源，内存自然就松了。
