Pagerfanta 不能直接集成 CodeIgniter，因其依赖 PSR-7/Symfony Request 而 CI3/4 使用自有请求机制；需手动实现 AdapterInterface、显式传页码、绕过内置 URI 解析，并避免自动加载冲突。
Pagerfanta 本身不原生支持 CodeIgniter，直接集成会报 Class 'Pagerfanta\Pagerfanta' not found 或路由/请求对象无法注入等错误——根本原因是 Pagerfanta 依赖 PSR-7 请求和 Symfony HttpFoundation 风格的 Request 对象，而 CodeIgniter 3/4 的请求处理机制完全不同。
为什么不能直接 new Pagerfanta($adapter) 后调用 setCurrentPage()？
CodeIgniter（尤其是 CI3）没有标准的 PSR-7 Request 实例，Pagerfanta 默认从 $_GET['page'] 读取页码，但 CI 的 URI 路由（如 /posts/page/2）或自定义分页参数名（如 ?p=3）会导致 getCurrentPage() 返回 1 或抛出异常。此外，CI 的数据库结果集是 CI_DB_result 对象，不是 Pagerfanta 认识的 AdapterInterface。
- 必须手动实现
Pagerfanta\Adapter\AdapterInterface，把$this->db->get()结果转为可计数、可切片的数据源 - 页码必须显式从
$this->uri->segment()（CI3）或$this->request->getGet('page')（CI4）提取，不能依赖 Pagerfanta 内置解析 - CI3 中需禁用自动加载冲突：避免 Composer 自动加载与 CI 的
Loader类重名（如Pagerfanta\Adapter\DoctrineORMAdapter会触发 CI 的doctrine加载器报错）
CI3 中手动封装 Adapter + 手动传页码的最小可行写法
以 CI3 为例，假设你查的是 posts 表，每页 10 条：
// 在控制器中
$this->load->database();
$offset = ($this->uri->segment(3)) ? $this->uri->segment(3) : 1;
$limit = 10;
$page = $offset; // segment(3) 就是页码，如 /posts/page/2 → offset=2
<p>// 手动查总数（避免子查询）
$total = $this->db->count_all('posts');</p><p>// 手动查当前页数据
$this->db->limit($limit, ($page - 1) * $limit);
$query = $this->db->get('posts');</p><p>// 构建简易 Adapter（无需完整实现，只满足 Pagerfanta 最小契约）
class CI3ArrayAdapter implements \Pagerfanta\Adapter\AdapterInterface
{
private $data;
private $total;</p><pre class="brush:php;toolbar:false;">public function __construct($data, $total) {
$this->data = $data;
$this->total = $total;
}
public function getNbResults() { return $this->total; }
public function getSlice($offset, $length) { return array_slice($this->data, $offset, $length); }}
// 使用 $adapter = new CI3ArrayAdapter($query->result(), $total); $paginator = new \Pagerfanta\Pagerfanta($adapter); $paginator->setCurrentPage($page); $paginator->setMaxPerPage($limit);
$data['posts'] = $paginator->getCurrentPageResults(); $data['pager'] = $paginator; $this->load->view('posts/index', $data);
CI4 中用 Query Builder + 自定义 Adapter 更稳妥
CI4 的 Query Builder 返回 BaseResult，但 getNumRows() 和 getResult() 可直接用。关键点：
- 不要用
$builder->paginate()—— 这是 CI4 原生分页，和 Pagerfanta 冲突 - Adapter 中的
getSlice()必须返回数组，$builder->get()->getResult()是对象数组，需保持一致 - CI4 的页码建议统一走 GET 参数：
$this->request->getGet('page', FILTER_SANITIZE_NUMBER_INT) ?: 1，避免 URI 段干扰 - 若启用缓存，Adapter 层需加
cache_key，否则每次请求都查总数
模板里渲染分页时绕过 Pagerfanta 的 View 依赖
Pagerfanta 自带的 Twig/PHP 模板（如 TwitterBootstrap3View）会尝试调用 $request->getRequestUri()，CI 不提供该方法。安全做法是手动拼 URL：
<?php foreach ($pager->getPages() as $page): ?>
<a href="?page=<?=%20%24page%20?>">= $page ?></a>
<?php endforeach; ?>
更健壮的方式是封装一个辅助函数，自动保留原有查询参数：build_page_url($page, ['sort' => 'date'])，否则点击分页会丢掉搜索条件。
真正麻烦的不是引入库，而是 Adapter 的边界处理——比如空数据时 getNbResults() 返回 0，但 getCurrentPageResults() 仍可能返回上一页残留；或者 MySQL 的 SQL_CALC_FOUND_ROWS 在高并发下不准，这些细节在 CI 环境里比在 Symfony 里更容易暴露。
