KnpPaginatorBundle 是 Symfony 中 Doctrine 分页最稳妥常用方案，三步完成：安装、注册、控制器调用 paginate() 并模板渲染；手动 offset/limit 仅适用于简单查询或 API；大数据量推荐游标分页；关联查询需防行数膨胀。
Doctrine分页在 Symfony 中最稳妥、最常用的方式是用
KnpPaginatorBundle
，它不是“可选插件”，而是社区事实标准。手动写
和
容易出错，尤其在关联查询、排序一致性、URL 参数继承、总条数统计这些环节。下面说清楚怎么落地。
用 KnpPaginatorBundle 实现标准分页
这是绝大多数场景的首选方案，三步就能跑通：
执行
在
中注册：
控制器中调用
，注意参数顺序必须是：
查询对象、当前页码、每页数量
例如：
模板里直接用
渲染分页导航——变量名必须是
，否则 URL 的
参数不会更新。
手写 offset/limit 分页（适合简单查询或 API 场景）
当不需要完整分页导航、只取某一页数据时（比如接口返回第 3 页的 20 条），可用原生 Doctrine 查询器：
用 QueryBuilder 构建查询，最后链式调用：
务必保证
ORDER BY 子句存在且稳定
（如按主键或带索引的时间字段），否则分页结果可能乱序、重复或遗漏
若需总数，单独执行
查询（注意避免 N+1）；大数据量时可考虑缓存总数或改用游标
大数据量遍历：用游标分页替代 offset
当处理百万级以上数据（如导出、批量通知），传统 offset 分页会越来越慢，甚至超时。这时应切换为游标分页：
核心是基于
唯一、有序字段
（如
或
）做条件查询：
每次请求返回下一页的游标值（即本页最后一条的
），前端下次带上它发起新请求
推荐使用
库，专为 Doctrine 设计，自动处理方向、边界、空结果等细节
优势：查询性能稳定、无 offset 性能衰减、天然避免因并发写入导致的数据跳过或重复
关联查询分页的常见陷阱
一对多或左连接后分页，容易出现“行数膨胀”问题：
比如用户表连订单表，一个用户有 5 个订单，
可能只查出 2 个用户，但返回了 10 行数据
解决办法：先分页主表 ID（子查询 or DQL with IN），再查详情；或改用
关联 +
方法
避免在分页前做
全量加载，否则内存直接爆掉
setFirstResult()setMaxResults()composer require knplabs/knp-paginator-bundleconfig/bundles.phpKnp\Bundle\PaginatorBundle\KnpPaginatorBundle::class => ['all' => true]$paginator->paginate()$query = $em->createQuery('SELECT u FROM App\Entity\User u ORDER BY u.createdAt DESC');
$pagination = $paginator->paginate(
$query,
$request->query->getInt('page', 1),
15
);{{ knp_pagination_render(pagination) }}paginationpage->setFirstResult(($page - 1) * $limit)->setMaxResults($limit)count()idcreatedAtWHERE id > :lastId ORDER BY id ASC LIMIT 100idsilarhi/cursor-paginationLIMIT 10EXTRA_LAZYslice()getResult()