DjangoRESTFramework怎么快速分页_Python利用Pagination实现数据切片
DRF默认分页类需显式启用：在视图类设pagination_class或继承GenericAPIView/ModelViewSet；自定义分页须继承PageNumberPagination并重写page_size或page_size_query_param；禁用分页设pagination_class = None；/api/items/?page=2返回空列表常见于参数错位、查询被意外过滤或QuerySet不可切片；扁平化响应需重写get_paginated_response()；关闭总数统计应重写get_count()返回None。
DRF 默认分页类怎么启用又不改全局配置
DRF 的 PageNumberPagination 默认不生效，必须显式挂载——要么在视图类里指定 pagination_class，要么在视图集里继承带分页的基类。直接写 APIView 时最容易漏掉这步，结果返回全部数据，前端卡死还查不出原因。
- 用
GenericAPIView或ModelViewSet时，默认已集成分页，但前提是没在 settings.py 里把DEFAULT_PAGINATION_CLASS设为None - 自定义分页类要继承
PageNumberPagination，并重写page_size或page_size_query_param；别直接改page_size类属性，它会被 DRF 缓存，多视图共用时互相污染 - 临时禁用分页？在视图类里设
pagination_class = None，比注释 settings 更安全，不影响其他接口
为什么 /api/items/?page=2 返回空列表但 total count 是 100
典型参数错位：前端传了 page=2，但后端实际按 limit/offset 解析（比如用了 LimitOffsetPagination），或数据库查询被额外过滤截断了结果集。DRF 分页只对最终 QuerySet 切片，不干预中间逻辑。
- 检查视图的
get_queryset()是否有未预期的.filter()或.exclude()，尤其涉及软删除字段（如is_deleted=True）时容易漏判 - 用
django-debug-toolbar看真实 SQL，确认 LIMIT/OFFSET 值是否匹配请求页码 ——page=2对应的 offset 应是(2-1)*page_size，不是2*page_size -
PageNumberPagination要求 QuerySet 可切片，如果中间用了.values_list('id', flat=True)再 .order_by()，可能触发TypeError: 'ValuesListQuerySet' object is not subscriptable
自定义分页响应结构：去掉嵌套的 results 字段
DRF 默认把数据包进 {"count": 100, "next": "...", "previous": "...", "results": [...]}，但前端团队可能要求扁平结构。不能靠序列化器改，得重写分页类的 get_paginated_response() 方法。
HaiSnap
一站式AI应用开发和部署工具
- 继承
PageNumberPagination，重写该方法，用Response({**data, "items": data.pop("results")})替换原逻辑，注意保留count和链接字段 - 别在视图里手动拼 JSON，否则丢失 DRF 的缓存头、Content-Range 支持，也绕过
paginate_queryset()的性能优化 - 如果用
CursorPagination，它不支持count，强行加会导致全表扫描，count字段必须设为None或用近似值
大表 COUNT(*) 拖慢接口：怎么关掉总数统计
当表行数超千万，SELECT COUNT(*) 会成为瓶颈，而前端可能根本不用 total 字段。DRF 允许关闭，但方式很隐蔽：不是删 count，而是让分页类返回 None。
- 重写分页类的
get_paginated_response()，把"count": self.page.paginator.count改成"count": None；但更彻底的是重写get_count()方法返回None，这样连 COUNT 查询都不发 - 用
CursorPagination天然不依赖 COUNT，适合日志、消息流等场景，但它要求排序字段有唯一索引，且不能跳页（无page=100） - 别在数据库层加
/*+ NO_COUNT */这类 hint，DRF 不识别，反而让 ORM 生成错误 SQL
分页逻辑越靠近 QuerySet 构建阶段越稳，一旦进了 Python 层再切片，内存和时间成本就失控了。尤其是 distinct()、annotate() 后的 QuerySet，分页前务必用 .explain() 看执行计划。