thinkphp分页必须作用于未执行的查询构造器，不可在模型静态方法或select()结果上调用；需显式指定数据库连接、正确传参并避免解包分页对象。
分页前必须指定数据库连接
ThinkPHP 的 paginate() 默认只作用于当前模型绑定的数据库连接，多库环境下若没显式切换，会直接报错或查错库。比如你用 Db::connect('mysql2') 查了数据，但紧接着调用 paginate() 却没传连接实例，它就会回退到默认连接（通常是 mysql1），导致数据和分页总数不一致。
正确做法是：把带连接的查询对象完整传递给 paginate()，而不是先取结果再分页。
- ✅ 正确：
Db::connect('mysql2')->name('user')->where('status', 1)->paginate(10) - ❌ 错误：
$list = Db::connect('mysql2')->...->select(); $list->paginate(10)（$list是 Collection，没有paginate方法） - 注意：模型类若指定了
protected $connection = 'mysql2'，则直接用UserModel::where(...)->paginate()即可，无需每次connect
跨库关联分页必须用原生 SQL 或子查询
ThinkPHP 的 join() 不支持跨数据库（如 mysql1.user 关联 mysql2.order），调用后会报错 Base table or view not found —— 因为底层执行时只在单个连接里找表。
真要实现跨库关联分页，得绕过 ORM 的 join 机制：
- 先查主表分页数据（例如从
mysql1.user分页查出 10 条 ID），用field('id')+paginate()得到$pageData - 取出 ID 列表：
$ids = $pageData->column('id') - 再用
Db::connect('mysql2')查副表：Db::connect('mysql2')->name('order')->where('user_id', 'in', $ids)->select() - 最后手动合并（用 PHP 关联）或改用
Db::query()写带JOIN的原生 SQL，但要注意数据库用户要有跨库权限
自定义分页参数容易被连接配置覆盖
多库项目常会为不同库配不同前缀、读写分离、断线重连策略，这些配置会影响 paginate() 底层的 COUNT 查询行为。比如你在 database.php 里给 mysql2 配了 'break_reconnect' => true，但分页时 COUNT 查询因超时失败，框架可能静默返回空分页器，而不是抛异常。
排查这类问题的关键点：
- 开启 SQL 日志：
'log_sql' => true，确认分页生成的两个 SQL（COUNT 和 LIMIT）是否都走对了连接 - COUNT 查询不走缓存，但如果你用了
cache(true)在分页链路上，会导致分页器缓存的是旧数据 —— 多库场景下尤其危险 - 不要在分页前调用
Db::close()或手动unset($db)，ThinkPHP 的连接池会复用，强制关闭可能导致后续分页拿不到有效连接
分页器渲染时无法自动适配不同库的 URL 参数
paginate() 返回的分页器对象默认只认当前请求的 GET 参数，如果分页链接需要携带库标识（例如 ?db=mysql2&page=2），它不会自动保留。用户点第二页时，db 参数就丢了，导致查回默认库。
解决方式很简单，但容易漏：
- 在模板中调用
$list->render()前，先设置参数：$list->appends(['db' => 'mysql2']) - 更稳妥的做法是统一在基类控制器里处理：
$this->assign('page', $list->appends(request()->param()));，避免漏传业务参数 - 注意：如果用了路由变量（如
route('user.index', ['db' => 'mysql2'])），需确保分页器生成链接时能识别该变量，否则要重写Page::setPath()
跨库分页真正麻烦的不是语法，而是每个环节都默认假设“单库”，一旦连接、关联、缓存、URL 任一环没对齐，分页数据就悄无声息地错掉。动手前先确认当前 Db::getConnect() 返回的是哪个实例，比写十行 paginate 更重要。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
