withtrashed()本质是移除deleted_at is null条件，但受全局作用域、调用顺序及关联模型独立性影响，需确保置于链首、检查basescope()、显式配置关联软删除。
ThinkPHP 模型启用软删除后，withTrashed() 不是“查出已删除数据”这么简单——它本质是移除默认的 deleted_at IS NULL 查询条件，但后续链式调用（比如 where()、order()）仍受模型全局作用域影响，不加注意容易查不到预期数据。
为什么 withTrashed() 查不到已软删除的记录
常见错误是直接在模型上调用：UserModel::withTrashed()->where('id', 1)->find()，结果仍返回 null。原因在于 ThinkPHP 的 withTrashed() 只临时禁用软删除过滤，但若模型定义了全局作用域（baseScope()），且该作用域里又手动加了 where('deleted_at', null) 或类似逻辑，就会二次过滤。
- 检查模型中是否重写了
baseScope()方法，删掉或绕过其中对deleted_at的硬性限制 -
withTrashed()必须放在查询链最前面，否则像where()->withTrashed()是无效的（方法顺序错） - 若使用了软删除字段别名（如
is_deleted），需确认useSoftDelete配置里的field和time是否匹配实际字段类型（布尔值 vs 时间戳）
withTrashed()、onlyTrashed()、restore() 的行为差异
三者操作目标不同，生成的 SQL 条件也不同，不能混用或误判返回结果：
-
withTrashed()→ 移除所有deleted_at IS NULL条件，查全部（含 deleted_at 非空） -
onlyTrashed()→ 只保留deleted_at IS NOT NULL，专查已软删除记录 -
restore()→ 不是查询方法，是模型实例方法，仅对单条数据生效，且要求该记录当前deleted_at非空；批量恢复需用where('deleted_at', 'neq', null)->update(['deleted_at' => null])
示例：UserModel::onlyTrashed()->where('status', 1)->select() 能查到 status=1 且已被软删除的用户；但 UserModel::withTrashed()->where('status', 1)->select() 返回的是 status=1 的所有用户（无论是否删除）。
联合查询 + 软删除时 withTrashed() 失效怎么办
当使用 join() 或关联查询（如 has()、with()）时，withTrashed() 默认只作用于主模型，关联模型仍走默认软删除逻辑。例如：OrderModel::withTrashed()->with('user')->find(1)，订单能查到已删除的，但关联的 user 若已软删除，依然为 null。
- 解决办法：在关联定义里显式调用
withTrashed()，比如在OrderModel的user()关联方法中返回$this->belongsTo(UserModel::class)->withTrashed() - 或者改用闭包预载：
with(['user' => function ($query) { $query->withTrashed(); }]) - 注意：
join()类型关联无法通过模型方法控制，需手写join()并显式写出ON user.deleted_at IS NULL OR user.deleted_at IS NOT NULL这类条件
软删除不是开关一开就万事大吉，withTrashed() 的作用范围、链式调用顺序、关联模型的独立控制，这三点最容易漏掉。尤其在复杂查询或团队协作项目里，一个没写全的 withTrashed() 就会让“明明删了却还能看到”的问题反复出现。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
