KnpPaginatorBundle是Symfony最稳妥省事的分页方案，因其自动处理排序一致性、关联查询行数膨胀、URL参数继承及总数统计等易错环节；手动offset/limit易导致乱序、重复、OOM及参数丢失。
直接用 KnpPaginatorBundle 是当前 Symfony 项目里最稳、最省事的分页方案，其他方式要么漏关键细节，要么只适合特定场景。
为什么不能手写 setFirstResult() + setMaxResults()
手动拼 offset/limit 看似简单，但实际运行中容易崩在几个地方：
- 没加
ORDER BY或字段没索引 → 分页结果乱序、重复、跳行 - 关联查询（比如
JOIN用户和订单）→COUNT(*)和LIMIT结果行数不一致，总页数算错 - URL 参数（如
?q=foo&status=active）不会自动带进下一页链接，得自己merge查询参数 - 控制器里调
$query->getResult()再传给分页器 → 整个结果集先加载进内存，OOM 风险拉满
KnpPaginatorBundle::paginate() 的三个参数顺序不能错
这个方法签名是固定的：$paginator->paginate($query, $page, $limit, $request)。少一个或顺序错，行为就不可控：
- 把
$limit当成第二个参数传 → 分页器误认页码为条数，首页显示 1 条、第二页显示 2 条 - 漏掉
$request→ 报ArgumentCountError，因为分页器要靠它读page、sort等 query 参数 - 变量名不是
pagination→ 模板里{{ knp_pagination_render() }}渲染的链接永远是?page=1
大数据量时 totalCount 和游标分页怎么选
当查的表有百万级以上数据，KnpPaginatorBundle 默认的 COUNT + OFFSET 方式会越来越慢，甚至超时：
- 关掉总数统计：
['totalCount' => false]→ 分页导航变成“下一页”“上一页”，不显示总页数，性能立竿见影 - 换游标分页：用
id > :lastId替代OFFSET，推荐silarhi/cursor-pagination库，它专为 Doctrine 设计，自动处理方向、空结果、边界条件 - 别自己手写游标逻辑：漏掉
ORDER BY id ASC或没处理好最后一页边界，很容易漏数据
真正麻烦的从来不是“怎么分页”，而是“怎么让分页在排序变化、筛选参数、关联查询、大数据量这些条件下都不出错”。KnpPaginatorBundle 把这些坑都踩过一遍了，直接用它，比自己造轮子靠谱得多。
