软删除需同时满足模型使用SoftDeletes trait和数据表含deleted_at字段；默认查询自动排除已软删记录，查全部用withTrashed()，仅查已删用onlyTrashed()，restore()恢复，forceDelete()彻底删除。
软删除不是“删不掉”，而是 deleted_at 字段被设为当前时间，让模型自动从常规查询中隐身；没配对 SoftDeletes trait 或漏加数据库字段，就根本不会生效。
如何启用 SoftDeletes 并添加 deleted_at 字段
必须同时满足两个条件：模型使用 trait、数据表含 deleted_at 字段。缺一不可，否则调用 delete() 仍是硬删除。
- 在迁移中添加字段：
php artisan make:migration add_deleted_at_to_users_table --table=users
，然后在up()方法里写：$table->softDeletes();
- 在模型中引入 trait：
use Illuminate\Database\Eloquent\SoftDeletes;
并在类定义中声明：use SoftDeletes;
- 注意：字段名固定为
deleted_at，不能改；类型必须是timestamp（softDeletes()自动处理）
软删除后查询行为的变化
默认所有 Eloquent 查询（User::all()、User::where(...)->get()）自动排除 deleted_at IS NOT NULL 的记录。这是通过全局作用域实现的，无需手动加 whereNull('deleted_at')。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 查已软删除的数据：用
withTrashed()—— 包含deleted_at != null和null的记录 - 只查已软删除的数据：用
onlyTrashed()—— 仅deleted_at IS NOT NULL -
restore()可恢复单条或集合，它会把deleted_at设为NULL，不是重新插入 -
forceDelete()才是真正从数据库移除（跳过软删除逻辑）
常见踩坑点与兼容性注意
软删除不是魔法，很多地方需要显式干预，否则容易“以为删了，其实还在”或“想查却查不到”。
- 关联查询默认不穿透软删除：比如
User::with('posts')不会自动过滤掉已软删除的 posts，除非Post模型也启用了SoftDeletes并在关系定义中加->withTrashed() - 数据库约束冲突：如果表上有
UNIQUE约束（如邮箱唯一），软删除后重插同邮箱会报错 —— 因为记录物理还在，只是被隐藏了 - 索引建议：给
deleted_at加索引，尤其当表数据量大且频繁执行withTrashed()时，否则全表扫描很慢 - API 返回时别忘了判断：直接
return $user可能返回已被软删除的模型（比如通过 ID 强查），应主动检查$user->trashed()
最常被忽略的是：软删除状态不影响模型实例的属性访问，$user->deleted_at 是可读可赋值的，但直接改它不会触发任何钩子或同步状态，必须用 restore() 或 delete() 才行。
