CodeIgniter 3 分页必须在 SQL 层用 limit() 和 offset() 实现，并单独调用 count_all_results(NULL, FALSE) 获取准确总数，Pagination 类仅生成 HTML 链接，不处理数据库逻辑。
CodeIgniter 3 的 $this->db->get() 结果怎么分页？
不能直接对查询结果对象分页——$this->db->get() 返回的是 CI_DB_result 实例，它不带分页逻辑。分页必须在 SQL 层完成，靠 limit() 和 offset() 控制数据范围，再配合手动算总条数。
常见错误是先 $query = $this->db->get('users');，再试图对 $query 调用分页方法，这会报错或返回全部数据。
- 正确做法：把分页参数（当前页码、每页数量）转成
limit()和offset()值，拼进查询链 - 总记录数必须单独查一次，用
$this->db->count_all_results('users', FALSE)（加FALSE是为了复用 WHERE 条件） - 别用
count_all()，它忽略 WHERE，结果不准
为什么 CodeIgniter 3 的 pagination 类不自动处理数据库分页？
因为它的 Pagination 类只负责生成 HTML 页码链接，不碰数据库——它甚至不知道你用没用数据库、用的是哪张表。所谓“数据库分页”，其实是你手动控制 SQL 的 LIMIT + OFFSET，再把总条数喂给分页类。
- 典型流程：先算总条数 → 算出总页数 → 传给
$this->pagination->initialize()→ 再执行带limit()/offset()的查询 - 容易漏掉的点：
uri_segment配置必须和实际 URL 中页码所在段一致，比如example.com/users/page/3就得设'uri_segment' => 3 - 如果用了查询条件（如搜索关键词），WHERE 必须在 count 和 get 之前都应用，否则总数和列表数据对不上
$this->db->count_all_results() 和 $this->db->count_all() 差在哪？
前者统计「当前查询构建状态」下的行数（保留 WHERE、JOIN、GROUP BY 等），后者只查整张表的 COUNT(*)，完全无视你的查询条件。
- 用错就会导致：列表只显示 5 条匹配数据，但分页显示 100 页（因为
count_all()返回了全表总数） - 注意
count_all_results()默认会重置查询，加FALSE参数可保留条件：$this->db->count_all_results('users', FALSE) - 如果用了
select()或distinct()，也必须加FALSE，否则条件丢失
分页时 WHERE 条件重复写两次很麻烦，怎么避免？
把条件封装成方法或变量，而不是在 count 和 get 之间硬写两遍。最简方式是先构建好查询对象，再分别调用 count_all_results(NULL, FALSE) 和 get()。
$this->db->from('users');
$this->db->where('status', 'active');
if ($keyword) {
$this->db->like('name', $keyword);
}
$total = $this->db->count_all_results(NULL, FALSE); // 复用上面所有条件
$this->db->limit($per_page, $offset);
$query = $this->db->get(); // 同样复用
- 关键点：
from()和where()等方法是链式累积的，不会自动清空 - 别在中间调用
get()或count_all_results()之后再改条件——那之前的构建就失效了 - 如果用了子查询或复杂 JOIN，建议用查询绑定（
bind()）避免 SQL 注入，同时保持条件可复用
