ThinkPHP 6 子查询分页不能直接用 paginate()，因其底层 COUNT(*) 不支持带 GROUP BY、JOIN 或窗口函数的子查询，易报错或返回错误总数；须手动拆分统计与数据查询，确保 SQL 完全一致并显式加表别名。
ThinkPHP 6 的子查询分页为什么不能直接用 paginate()
因为 paginate() 底层依赖 COUNT(*) 统计总数，而子查询（尤其是带 GROUP BY、JOIN 或窗口函数的）在 MySQL 中无法被直接包裹进 SELECT COUNT(*) FROM (子查询) AS tp_count —— 多数版本会报错 Every derived table must have its own alias，或更隐蔽地返回错误总数（比如恒为 0 或 1）。
这不是 ThinkPHP 的 bug，是 SQL 标准和驱动限制。你得手动拆开「总数统计」和「数据查询」两步，且确保两个子查询逻辑完全一致（字段、条件、排序、关联）。
手动实现子查询分页：先算总数，再取数据
核心是用 Db::query() 或原生 count() 配合子查询字符串，绕过 ORM 的自动 count 封装。
- 把子查询写成完整 SQL 字符串（注意别漏
AS table_alias），用于COUNT(*)和LIMIT查询 - 总数统计：用
Db::query("SELECT COUNT(*) FROM ({$subSql}) AS tmp")，必须显式加别名AS tmp - 分页数据：用
Db::query("SELECT * FROM ({$subSql}) AS tmp LIMIT {$offset}, {$length}") - 构造
Paginator实例时，传入手动算出的$total和当前$page、$listRows
示例（查用户订单数 Top 10）：
立即学习“PHP免费学习笔记（深入）”；
$subSql = "(SELECT user_id, COUNT(*) as order_count FROM `order` GROUP BY user_id ORDER BY order_count DESC) AS user_top";
$total = (int) Db::query("SELECT COUNT(*) FROM {$subSql}")[0]['COUNT(*)'];
$list = Db::query("SELECT * FROM {$subSql} LIMIT 0, 10");
<p>$paginator = new LengthAwarePaginator($list, $total, 10, input('page/d', 1));
ThinkPHP 6.1+ 可用 paginate(false) + 手动 count，但仍有坑
paginate(false) 会跳过自动 count，但依然会尝试解析你的查询对象来拼 count SQL —— 如果原始查询含子查询（如 ->table('(...) AS t')），它大概率解析失败或生成非法 SQL。
- 安全做法：彻底放弃链式查询构建子查询，改用原生 SQL 字符串传给
Db::query() - 若坚持用 Query 对象，必须确保子查询已通过
->table()指定为字符串表名（如->table('(SELECT ...) AS t')），且后续不调用任何可能触发自动 count 的方法（如->where()再链式调用） -
->count()在子查询场景下不可信，它仍会尝试包裹，应一律用Db::query()手动执行 count SQL
容易被忽略的关键细节
子查询分页不是“写对一次就完事”，稍不注意就会导致页码错乱或数据重复/丢失。
- 两个子查询（count 和 limit）的
WHERE、JOIN、ORDER BY必须字面量完全一致，连空格和换行都不能差 —— 建议定义成同一个$subSql变量复用 - MySQL 5.7 默认不支持子查询带
ORDER BY（除非有LIMIT），所以ORDER BY要写在最外层，或确保子查询里有LIMIT占位（如ORDER BY x LIMIT 999999999） - 如果子查询里用了用户变量（
@var）或临时表，COUNT(*)查询会因会话隔离而失效，这类场景只能用缓存总数或业务层预计算
真正稳定的子查询分页，从来不是靠框架自动适配，而是靠你控制 SQL 的生成时机和结构一致性。
