thinkphp模型无真正默认排序，需用order()方法或作用域实现；多字段排序推荐二维数组写法order([['field1','asc'],['field2','desc']])，并务必用唯一字段兜底防分页错乱。
ThinkPHP模型查询默认排序怎么设
模型本身不自动带排序，所谓“默认排序”得靠 defaultOrder 属性或查询时显式指定。直接在模型类里写 protected $defaultOrder = ['id' => 'desc']; 是无效的——ThinkPHP 6.x 完全不识别这个属性，5.x 也只在极少数场景（如某些封装的列表方法）里可能被读取，但不可靠。
真正生效的方式只有两种：一是在查询构造器中调用 order()；二是把排序逻辑封装进模型的静态方法或作用域（scope）。推荐后者，更可控、可复用。
-
order()必须在最终执行前调用，链式调用中它要放在select()或find()之前 - 如果用了软删除（
use SoftDelete），order()仍有效，但要注意别和withTrashed()等混用导致语义混乱 - 全局作用域（
basescope）里加order()是可行的，但会强制所有查询都带上，容易掩盖业务意图，慎用
多字段排序时 order() 的参数怎么写才不翻车
ThinkPHP 的 order() 支持字符串、数组、表达式三种写法，但行为差异大，尤其在多字段时容易出错。最稳妥的是用二维数组：order([['sort', 'asc'], ['id', 'desc']])，字段名和方向一一对应，清晰且不会因键名重复被覆盖。
常见翻车点：用一维关联数组 order(['sort' => 'asc', 'id' => 'desc'])。这在 ThinkPHP 6.0.12+ 是支持的，但早期版本（如 6.0.8）会把后一个键值对覆盖前一个，最终只剩 id DESC；而 5.x 根本不认这种写法，直接报错 Call to a member function parseOrder() on null。
- 字符串写法
order('sort asc, id desc')最兼容，但字段名含空格或特殊字符时需手动加反引号，易漏 - 如果字段来自关联模型（比如
user.name），必须确保关联已预加载（with()）或使用子查询，否则排序字段不存在，SQL 直接报错Unknown column 'user.name' - 数据库层面，MySQL 5.7+ 默认 strict mode 下，
order by中出现未在group by中的非聚合字段会触发错误，此时不能只改 PHP 代码，得同步调整 SQL 模式或查询逻辑
order() 和数据库索引的关系容易被忽略
写了 order('status', 'asc')->order('created_at', 'desc')，不代表查询就快。MySQL 只有在存在符合最左前缀原则的联合索引时，才能高效走排序。比如建了 INDEX idx_status_created (status, created_at)，那这个双字段排序能用上；但如果只建了 (created_at, status)，或者两个单列索引，则大概率触发 Using filesort，数据量一大就明显卡顿。
- 用
EXPLAIN看执行计划，重点盯Extra列是否含Using filesort - ThinkPHP 日志里查不到索引是否命中，得去数据库原生查，别依赖框架日志判断性能
- 如果排序字段是计算字段（如
orderRaw('LENGTH(title) desc')），索引完全失效，只能靠缓存或预计算列来优化
分页 + 多字段排序时 order() 的顺序影响结果稳定性
分页结果跳变，八成是因为排序字段有重复值。比如按 status 排序，多个记录 status 都是 1，数据库返回顺序就不确定，第一页和第二页可能把同一批记录切散。解决办法是：在主排序字段后，**必须补一个唯一字段（通常是主键）作为兜底**。
- 正确写法：
order([['status', 'asc'], ['id', 'asc']])，哪怕业务上觉得 status 已足够区分 - 错误写法：
order('status asc')单字段，尤其在高并发插入场景下，分页接口返回内容可能前后不一致 - 如果主键不是自增整型（比如 UUID），补
id仍可能不够稳定，这时得用时间戳字段（如create_time）+ 主键组合，确保排序键全局唯一
这个细节在测试环境很难暴露，往往上线后用户反馈“列表刷着刷着就乱了”，才意识到是排序键没做全。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
