Laravel模型删除？删除操作怎样执行？

Laravel模型删除推荐使用软删除，通过引入SoftDeletes Trait并添加deleted_at字段，调用delete()时仅标记删除而非物理移除；软删除便于数据恢复与审计，适用于用户内容、订单等关键数据；关联删除建议用模型事件手动处理以兼容软删除，避免数据库级联的局限；批量删除可提升性能，但不触发事件，大数量操作宜结合chunkById分块处理，并用事务保证数据一致性。

Laravel模型删除主要通过调用模型实例的

delete()

解决方案

谈到Laravel的模型删除，我们通常会遇到几种场景，每种都有其适用性。最直接的方式，当然是找到模型实例，然后调用它的

delete()

use App\Models\User;

$user = User::find(1);
if ($user) {
    $user->delete(); // 这会将记录从数据库中永久删除
}

或者，如果你想删除一组特定的记录，你可以结合查询构建器：

// 删除所有状态为 'inactive' 的用户
User::where('status', 'inactive')->delete();

甚至，如果你知道多个ID，可以直接用

destroy

// 删除ID为1、2、3的用户
User::destroy(1, 2, 3);

不过，我个人在实际项目中，除非有非常明确的业务需求，比如清理临时数据或者GDPR合规性要求，否则很少会直接执行这种“硬删除”。因为一旦删了，数据就真的没了，后悔药都没地方买。这时，软删除（Soft Deletes）就成了我的首选。

启用软删除非常简单。在你的模型中引入

SoftDeletes

deleted_at

timestamp

// 在User模型中
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\SoftDeletes; // 引入SoftDeletes

class User extends Model
{
    use HasFactory, SoftDeletes; // 使用SoftDeletes Trait

    // ...
}

对应的迁移文件大概会是这样：

Schema::table('users', function (Blueprint $table) {
    $table->softDeletes(); // 添加deleted_at字段
});

一旦启用了软删除，当你调用

$user->delete()

deleted_at

Laravel软删除（Soft Deletes）究竟是如何工作的？何时应该使用它？

软删除的原理其实很简单，它利用了一个特殊的

deleted_at

delete()

DELETE

WHERE deleted_at IS NULL

那么，何时应该使用软删除呢？在我看来，几乎所有涉及到用户生成内容、核心业务数据（如订单、商品、文章等）、或者任何你可能需要追溯、恢复的数据，都应该考虑使用软删除。

想象一下，一个用户不小心删除了自己发布的一篇重要文章，如果你的系统是硬删除，那这篇文章就真的找不回来了，用户体验会很糟糕。但如果使用了软删除，管理员或者用户自己（如果你提供这个功能）可以轻松地通过

restore()

$deletedUser = User::withTrashed()->find(1); // 查找包括软删除在内的所有记录
if ($deletedUser) {
    $deletedUser->restore(); // 恢复用户，将deleted_at设为NULL
}

甚至，你还可以只查询那些被软删除的记录：

$onlyDeletedUsers = User::onlyTrashed()->get(); // 只获取被软删除的用户

软删除的优势在于：

• 数据恢复方便：这是最大的优点，误操作后可以轻松恢复。
• 审计追踪：

  deleted_at

  登录后复制
  字段本身就是一种删除时间记录，便于追溯。
• 业务逻辑灵活：有些业务场景下，我们可能需要保留已删除数据的一部分信息，软删除完美契合。

当然，它也不是没有缺点。最明显的就是，它会增加数据库的存储空间，并且查询时需要额外的

WHERE

处理Laravel模型删除时的关联数据：级联删除（Cascade Delete）与手动处理的权衡？

处理关联数据是模型删除时一个常见的痛点。比如，你删除了一个用户，那么这个用户发布的所有文章、评论是否也应该一并删除？这里通常有两种主流策略：数据库层面的级联删除（Cascade Delete）和应用层面的手动处理（通过模型事件）。

数据库层面的级联删除

这种方式是在数据库迁移文件中定义外键约束时，指定

onDelete('cascade')

Alkaid.art

专门为Phtoshop打造的AIGC绘画插件

153

查看详情

// 在文章表的迁移文件中
Schema::table('posts', function (Blueprint $table) {
    $table->foreign('user_id')
          ->references('id')->on('users')
          ->onDelete('cascade'); // 当用户被删除时，其所有文章也会被删除
});

它的优点显而易见：

• 简单高效：一旦设置，数据库会自动处理，无需编写额外代码。
• 数据一致性：数据库保证了关联数据的完整性。

但缺点也很明显：

• 缺乏控制：一旦触发，就无法干预。如果某个子记录不应该被删除，或者删除前需要执行某些业务逻辑，级联删除就显得过于粗暴。
• 与软删除的冲突：如果你父模型使用了软删除，数据库层面的

  onDelete('cascade')

  登录后复制
  并不会被触发，因为软删除只是更新了

  deleted_at

  登录后复制
  字段，而不是真正的

  DELETE

  登录后复制
  操作。这是一个很多人会踩的坑。

应用层面的手动处理（通过模型事件）

这通常是我更倾向的做法，尤其是在父模型启用了软删除或者删除逻辑比较复杂的情况下。Laravel的模型事件（Model Events）允许你在模型生命周期的特定阶段执行代码，比如在

deleting

deleted

// 在User模型中
class User extends Model
{
    use HasFactory, SoftDeletes;

    protected static function booted()
    {
        static::deleting(function ($user) {
            // 当用户被删除时（无论是软删除还是硬删除），删除其所有文章
            // 注意：这里我们调用文章的delete()方法，如果文章也启用了软删除，
            // 那么它们也会被软删除，而不是硬删除。
            $user->posts()->each(function ($post) {
                $post->delete();
            });

            // 也可以删除其他关联数据，比如评论
            $user->comments()->delete();
        });
    }
}

这种方式的优点是：

• 高度灵活：你可以在删除前或删除后执行任何复杂的业务逻辑。
• 兼容软删除：无论父模型是软删除还是硬删除，事件都会触发，你可以在事件中决定子模型是软删除还是硬删除。
• 可控性强：可以有选择性地删除部分关联数据，或者在删除前进行验证。

缺点是：

• 需要编写更多代码：对于每个需要级联删除的模型，你都需要编写相应的事件监听逻辑。
• 潜在的性能问题：如果关联数据量非常大，循环删除可能会导致N+1查询问题，需要优化。

权衡之下，我通常建议：对于简单、纯粹的物理级联删除，且父模型不使用软删除的情况，可以考虑数据库层面的

onDelete('cascade')

Laravel模型删除过程中常见的错误与性能优化策略有哪些？

在处理Laravel模型删除时，我见过不少开发者犯过一些常见的错误，也总结了一些提升性能的策略。

常见的错误：

1. 忽略软删除的特性：最常见的错误就是以为调用

   delete()

   登录后复制
   就彻底没了，结果发现数据还在，只是被标记了。如果你需要彻底删除，记得使用

   forceDelete()

   登录后复制
   。反之，如果你想恢复，却不知道要用

   withTrashed()

   登录后复制
   和

   restore()

   登录后复制
   。
2. 忘记处理关联数据：这是个大坑。删除了父记录，子记录却还在，导致数据不一致。比如，删除了一个相册，里面的照片却成了“孤儿”，这不仅占用空间，还可能导致程序出错。
3. N+1删除问题：当通过循环调用

   $model->delete()

   登录后复制
   来删除大量记录时，如果

   deleting

   登录后复制
   或

   deleted

   登录后复制
   事件中包含了关联查询或操作，就很容易出现N+1问题。例如，在

   deleting

   登录后复制
   事件中加载关联模型来删除它们，如果每次都重新查询，就会造成大量数据库请求。
4. 不使用事务：在执行一系列复杂的删除操作时，如果没有用数据库事务包裹，一旦中间某个环节出错，部分数据可能已经被删除，导致数据状态不一致。
5. 在循环中频繁实例化模型：如果你要删除大量记录，尽量避免在循环中每次都

   new Model()

   登录后复制
   然后

   save()

   登录后复制
   或

   delete()

   登录后复制
   。这会创建大量的Eloquent模型实例，消耗内存。

性能优化策略：

1. 批量删除：对于大量记录的删除，尽量使用查询构建器直接执行批量删除，而不是循环遍历每个模型实例然后调用

   delete()

   登录后复制
   。

   // 假设要删除所有状态为 'pending' 的订单
   Order::where('status', 'pending')->delete(); // 这会直接执行一条SQL DELETE语句

   登录后复制

   这样做的好处是，它通常只执行一条SQL语句，效率极高。但需要注意的是，这种方式不会触发模型的

   deleting

   登录后复制
   和

   deleted

   登录后复制
   事件。如果你的业务逻辑依赖这些事件，就不能直接使用这种方式。

2. 分块删除（Chunking）：如果你需要删除的记录数量非常庞大（比如几十万上百万），并且需要触发模型事件，那么一次性加载所有记录到内存可能会导致内存溢出。这时，可以使用

   chunk()

   登录后复制
   或

   chunkById()

   登录后复制
   方法分批处理：

   User::where('created_at', '<', now()->subYears(5))
       ->chunkById(1000, function ($users) {
           foreach ($users as $user) {
               $user->delete(); // 这里会触发软删除和相关事件
           }
       });

   登录后复制

   这样每次只加载一小部分记录到内存，可以有效避免内存问题。

3. 禁用事件（谨慎使用）：在极少数情况下，当你需要删除大量记录且确定不需要触发任何模型事件时，可以临时禁用事件来提升性能。

   // 禁用所有User模型的事件
   User::withoutEvents(function () {
       User::where('status', 'old')->delete();
   });
   // 或者只禁用特定事件
   User::unsetEventDispatcher(); // 全局禁用
   // ... 执行删除 ...
   User::setEventDispatcher(app('events')); // 恢复事件调度器

   登录后复制

   这种做法需要非常小心，因为它可能会绕过一些重要的业务逻辑或数据一致性检查。

4. 使用数据库事务：对于任何涉及多个步骤、需要保持数据一致性的删除操作，务必使用数据库事务。

   DB::transaction(function () {
       $user = User::find(1);
       if ($user) {
           $user->posts()->delete(); // 删除用户所有文章
           $user->comments()->delete(); // 删除用户所有评论
           $user->delete(); // 软删除用户
       }
   });

   登录后复制

   这样可以确保要么所有操作都成功，要么所有操作都回滚，避免数据处于不一致状态。

总之，Laravel的模型删除功能强大且灵活，但理解其背后的机制，特别是软删除和事件系统，对于写出健壮、高效且不易出错的代码至关重要。

以上就是Laravel模型删除？删除操作怎样执行？的详细内容，更多请关注php中文网其它相关文章！