thinkphp分页混乱主因是排序失控：必须显式order()且置于paginate前；多表需带别名；排序字段须有匹配索引；参数要透传；高并发宜用cursorpaginate+复合排序兜底。
ThinkPHP分页混乱，本质不是分页写错了，而是排序没控住——没加 ORDER BY，或加了但没走索引、字段重复、参数没透传。只要抓住这四点，基本就能稳住。
必须显式写 order()，且放在 select 前
paginate() 不会自动补排序，不写 order 就等于把排序交给 MySQL 随机决定，翻页时数据跳动、重复、漏条全是常态。
- ✅ 正确写法：
User::order('id desc')->paginate(15)或User::order(['create_time' => 'desc', 'id' => 'desc'])->paginate(15) - ❌ 错误写法：
User::paginate(15)（无序）、User::select()->paginate(15)（已执行查询，退化为内存切片） - 多表关联时，order 字段必须带别名，例如
->join('profile p', 'user.id = p.user_id')->order('p.sort desc')，否则报错“Column 'sort' is ambiguous”
排序字段必须有索引，且顺序匹配
EXPLAIN 出现 Using filesort，说明 MySQL 没用上索引排序，只能临时排序——性能差，还容易翻页错乱。
- 常见坑：where('status', 1)->order('create_time desc')，但只建了
(status)单列索引 → 应建联合索引(status, create_time) - 游标分页（如 cursorPaginate）要求 order 字段严格非空、单调、可比较；主键 id 天然满足，create_time 则需设
NOT NULL DEFAULT '1970-01-01'并配(create_time, id)索引 - 避免对排序字段做函数处理，比如
orderRaw("DATE(create_time) desc")或whereRaw("YEAR(create_time) = ?")，索引直接失效
筛选条件要随分页一起透传
点第二页变成 ?page=2，start_time、keyword 全丢了？这不是 bug，是 paginate 默认只读 page 参数。
- 安全写法：
->paginate(15, false, ['query' => array_filter(request()->only(['start_time', 'end_time', 'status', 'keyword']))]) - 千万别用
['query' => request()->param()]全量透传，可能把 token、_csrf 等敏感参数也带上 - 模板中渲染分页：
{$list->render()}，不是{$page|raw}或手动拼 URL
高并发下防时间戳重复导致漏数据
create_time 相同的订单一多，ORDER BY create_time DESC LIMIT 10 OFFSET 20 就可能跳过某些记录，尤其深度翻页时。
- 复合排序兜底：
->order('create_time desc, id desc')，确保每条记录排序值唯一 - 更优解：改用游标分页
User::order('id desc')->cursorPaginate(20)，基于主键，天然稳定、无 offset 性能衰减 - NULL 值必须处理：要么数据库层设
create_time NOT NULL，要么应用层写入时强制补默认值，否则 cursorPaginate 会报错或行为异常
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
