Laravel通过SoftDeletes Trait实现软删除，核心是在删除时标记deleted_at字段而非物理删除。需在数据库添加deleted_at字段并使用SoftDeletes Trait。启用后，delete()方法会更新deleted_at，查询自动排除已删除数据。提供withTrashed()、onlyTrashed()、restore()和forceDelete()方法管理删除状态。优势包括数据可恢复、审计追踪和回收站功能，但需注意唯一约束冲突和关联模型处理。解决方案包括组合索引、条件索引及事件监听实现级联软删除，确保业务逻辑完整性。

Laravel实现软删除功能，主要是通过其Eloquent ORM提供的SoftDeletes Trait。这个机制的核心思想是，当你“删除”一条记录时，它并不会真正从数据库中消失，而是会在记录中标记一个时间戳（通常是deleted_at字段），表明这条记录在逻辑上已被删除。这样一来，数据依然存在，便于后续的恢复或审计。

解决方案

要在Laravel中启用软删除，你需要做两件事：

1. 在数据库表中添加deleted_at字段。 这是最关键的一步。这个字段通常是一个TIMESTAMP类型，并且允许为NULL。Laravel提供了一个方便的迁移（migration）方法来完成这个：

   Schema::table('your_table_name', function (Blueprint $table) {     $table->softDeletes(); // 这会添加一个nullable的deleted_at TIMESTAMP字段 });

   如果你需要回滚，可以使用：

   Schema::table('your_table_name', function (Blueprint $table) {     $table->dropSoftDeletes(); });

2. 在对应的Eloquent模型中使用SoftDeletes Trait。

   <?php  namespace AppModels;  use IlluminateDatabaseEloquentFactoriesHasFactory; use IlluminateDatabaseEloquentModel; use IlluminateDatabaseEloquentSoftDeletes; // 引入SoftDeletes Trait  class Post extends Model {     use HasFactory, SoftDeletes; // 使用SoftDeletes Trait      // ... 其他模型定义 }

完成这两步后，当你对Post模型实例调用delete()方法时，Laravel不会执行DELETE SQL语句，而是执行一个UPDATE语句，将deleted_at字段设置为当前时间。

$post = Post::find(1); $post->delete(); // 这条记录的deleted_at字段会被填充

默认情况下，所有通过Eloquent查询Post模型的语句都会自动排除那些deleted_at不为NULL的记录。这意味着，你不需要在每次查询时手动添加deleted_at4条件，Eloquent已经帮你处理了。这在我看来，是软删除最“香”的地方之一，大大简化了业务逻辑代码。

Laravel中软删除的优势与应用场景是什么？

在我看来，软删除在现代Web应用中几乎是不可或缺的。它带来的最直接的优势就是数据安全性和可恢复性。想象一下，如果一个用户不小心删除了重要数据，或者运营人员误操作，如果没有软删除，那数据就真的灰飞烟灭了。有了它，恢复数据就变得轻而易举，这在很多时候能避免一场潜在的灾难。

再者，它对审计追踪也很有帮助。有时我们需要知道一条数据是什么时候被“删除”的，谁删除的，软删除的deleted_at字段就提供了这样的线索。这比直接从数据库中抹去记录要友好得多。我记得有一次，我们产品上线初期，因为业务逻辑还在频繁调整，误删数据是常有的事。如果没有软删除，那简直是噩梦。

从用户体验角度看，软删除也提供了更多可能性。比如，很多应用都有“回收站”功能，用户可以从回收站找回自己删除的内容。这背后，就是软删除在默默支持。

当然，它也不是没有缺点。最明显的就是数据库存储空间的占用。被软删除的数据仍然占据着存储空间，并且在查询时，deleted_at4这样的条件，虽然Eloquent帮你处理了，但本质上还是一个额外的条件，可能会对查询性能有轻微影响，尤其是在数据量非常庞大的情况下。不过，在大多数业务场景下，这些影响都可以通过合理的索引和数据库优化来缓解，其带来的便利性远超这些小小的代价。

如何查询和恢复被软删除的数据？

当数据被软删除后，默认的Eloquent查询是看不到它们的。但Laravel提供了一系列方法来让你灵活地操作这些“已删除”的数据。

1. 查询所有记录（包括软删除的）：deleted_at7

如果你想获取某个模型的所有记录，无论它们是否被软删除，你可以在查询时链式调用deleted_at7方法：

$allPosts = Post::withTrashed()->get(); // 获取所有文章，包括已删除的

这个方法在我看来非常实用，特别是在后台管理系统，管理员需要查看所有状态的数据时。

2. 仅查询被软删除的记录：deleted_at9

如果你只对那些已经被软删除的记录感兴趣，比如要实现一个“回收站”功能，deleted_at9就派上用场了：

$deletedPosts = Post::onlyTrashed()->get(); // 只获取被软删除的文章

结合分页，你可以轻松构建一个回收站页面。

3. 恢复被软删除的记录：deleted_at1

恢复数据和删除数据一样简单，只需要对模型实例调用deleted_at1方法即可：

$post = Post::onlyTrashed()->find(1); // 先找到被软删除的记录 if ($post) {     $post->restore(); // 将deleted_at字段设为NULL，数据恢复 }

deleted_at1方法会将deleted_at字段重新设置为NULL，这样这条记录就又会出现在常规查询结果中了。这操作简直是“后悔药”，非常好用。

4. 彻底删除（硬删除）被软删除的记录：deleted_at6

腾讯智影-AI数字人

基于AI数字人能力，实现7*24小时AI数字人直播带货，低成本实现直播业务快速增增，全天智能在线直播

73

查看详情

有时，你确实需要彻底地从数据库中移除一条记录，比如清理垃圾数据或者满足GDPR等合规性要求。这时，你可以使用deleted_at6方法：

$post = Post::onlyTrashed()->find(1); // 找到被软删除的记录 if ($post) {     $post->forceDelete(); // 这次是真的从数据库中删除了 }

值得注意的是，deleted_at6会绕过软删除机制，直接执行DELETE SQL语句。所以，在使用这个方法时务必谨慎，一旦执行，数据就真的找不回来了。我通常会把这个功能放在非常高的权限层级，或者在夜间定时任务中执行，以避免误操作。

软删除在关联关系和唯一约束中可能遇到哪些挑战及解决方案？

软删除虽然好用，但在处理关联关系和数据库唯一约束时，确实有一些需要注意的“坑”。这些往往是初学者容易忽略，但在实际项目中又不得不面对的问题。

1. 唯一约束（Unique Constraints）的挑战

这是软删除最常见的陷阱之一。假设你有一个TIMESTAMP0表，其中TIMESTAMP1字段有一个唯一索引。如果你软删除了一个名为“Apple”的产品，然后又想创建一个新的名为“Apple”的产品，数据库会报错，因为它仍然认为那个被软删除的“Apple”产品是存在的，导致唯一性冲突。

解决方案：

最常见的做法是，将唯一索引设置为作用于TIMESTAMP1字段和deleted_at字段的组合，并且在deleted_at为NULL时才强制唯一。这通常通过数据库的“部分索引”（Partial Index）或“条件索引”（Conditional Index）来实现。

例如，在MySQL中，你可以创建一个这样的索引：

ALTER TABLE products ADD UNIQUE INDEX unique_name_not_deleted (name, deleted_at);

但这并不能完全解决问题，因为deleted_at是NULL和具体时间戳两种情况。更好的做法是，在你的迁移文件中，对deleted_at字段添加一个默认值（比如一个未来的时间戳，或者干脆让它参与到索引中，但这个需要数据库支持条件索引）。

一个更直接且跨数据库的通用方法是，在你的数据库迁移中，为唯一性约束添加一个条件，只在deleted_at为NULL时才生效。但这需要数据库本身支持这种语法，比如PostgreSQL的NULL1。

在MySQL中，如果不支持条件索引，一种变通方案是：将唯一索引应用于TIMESTAMP1和deleted_at字段的组合，但允许deleted_at为NULL。当记录被软删除时，deleted_at会被填充，这样它和TIMESTAMP1的组合就不再与未删除的记录冲突了。但这意味着你不能有两个未删除的相同TIMESTAMP1，也不能有两个已删除的相同TIMESTAMP1，除非你对deleted_at字段做些特殊处理，例如将其设为非NULL的唯一值。

更实用的做法是，在应用层面，当创建新记录时，先检查是否存在同名的未删除记录。如果存在，阻止创建；如果存在同名的已删除记录，并且业务允许，可以考虑先恢复再更新，或者强制删除旧的再创建新的。这需要更多的业务逻辑判断。

2. 关联关系中的挑战

当一个模型被软删除时，它所关联的子模型（例如，一个Post有多个SoftDeletes3）是应该一起被软删除，还是保持不变？

解决方案：

• 级联软删除（Cascading Soft Deletes）： 你可以在父模型被软删除时，也自动软删除其所有子模型。这可以通过在父模型的SoftDeletes4事件中监听并手动软删除关联模型来实现：

  class Post extends Model {     use HasFactory, SoftDeletes;      protected static function booted()     {         static::deleting(function ($post) {             // 软删除所有关联的评论             $post->comments()->each(function ($comment) {                 $comment->delete(); // 这会触发Comment模型的软删除             });         });          static::restoring(function ($post) {             // 恢复时，也恢复所有关联的评论             $post->comments()->onlyTrashed()->each(function ($comment) {                 $comment->restore();             });         });     }      public function comments()     {         return $this->hasMany(Comment::class);     } }

  这种方式需要手动编写事件监听器，但提供了极大的灵活性。

• 查询关联模型时排除已删除的父模型： 默认情况下，当你通过一个已被软删除的父模型去查询其关联模型时，Laravel会正常返回结果。但如果你只想获取那些父模型未被软删除的子模型，你可能需要在查询子模型时额外添加条件，或者使用全局作用域（Global Scopes）。

  例如，如果你想获取所有未被删除的文章的评论：

  Comment::whereHas('post', function ($query) {     $query->whereNull('deleted_at'); // 或者 $query->withoutTrashed(); })->get();

  或者，如果你的SoftDeletes3模型也使用了SoftDeletes，并且你只关心未被删除的评论：

  Post::with('comments')->get(); // 默认只会加载未被删除的Post和未被删除的Comment Post::withTrashed()->with('comments.withTrashed')->get(); // 加载所有Post和所有Comment

这些细节处理起来确实需要一些思考，但一旦理解了软删除的机制，并且在设计数据库和模型时就考虑到这些情况，就能避免很多后期维护的麻烦。我个人倾向于在设计初期就明确哪些关联需要级联软删除，哪些不需要，这样可以省去不少返工的精力。

以上就是Laravel如何实现软删除功能_数据逻辑删除与恢复的详细内容，更多请关注laravel mysql php cad app ai apple 数据恢复 sql语句 作用域 laravel sql mysql NULL timestamp Conditional delete 作用域 事件 postgresql 数据库