引言
我们不止一次在系列文章中讲到模型的“软删除”功能，因为现实场景中为了保证数据可追溯，我们几乎不会对数据库进行物理删除。删除数据有可能会造成数据一致性的破坏，进而导致业务逻辑无法跑通。所以，软删除的概念，极为重要。
本文我们仍然不厌其烦地讲解软删除的功能。
物理删除
其实就是真实地把数据从数据库条目清除，laravel模型提供了开箱即用的方法。比如下面这样使用：
$event = Event::find(12);
$event->delete();
首先使用primary key查询出需要的条目，返回一个Event对象实例，然后调用 delete 方法进行删除。真实的SQL如下：
DELETE FROM events WHERE id = 12;
laravel提供了许多语法糖，上面使用 find 和 delete 两个步骤，可以缩减为一个方法 destroy，用法如下：
Event::destroy(12);
这样一行就搞定了。
软删除
在许多情况下，你不会真正想要从数据库中删除记录，而是用一种不再在应用程序中显示它们的方式对其进行注释。这就是所谓的软删除。
Laravel本身支持软删除，只需要进行少量的配置更改，以确保在执行delete或destroy时，模型的记录不会被实际删除。作为一个例子，我们修改Event模型以支持软删除。
首先创建一个新的迁移，将名为deleted_at的列添加到events表中：
php artisan make:migration add_soft_delete_to_events --table=events
执行成功，输出内容如下：
Created Migration: 2020_10_08_184402_add_soft_delete_to_events
接着在生成的迁移文件内实现迁移使用的 up 方法：
public function up()
{
Schema::table('events', function(Blueprint $table)
{
$table->softDeletes();
});}
还有用于迁移回滚的 down 方法：
public function down()
{
Schema::table('events', function(Blueprint $table)
{
$table->dropColumn('deleted_at');
});}
修改完毕，在命令行执行迁移指令：
php artisan migrate
执行成功输出内容：
Migrating: 2020_10_08_184402_add_soft_delete_to_events
Migrated: 2020_10_08_184402_add_soft_delete_to_events
模型SoftDelete
有了数据库表的支持，我们才能在模型内使用软删除的功能。
其实原理很简单，就是为模型追加一个全局作用域，为每个查询子句追加上如下筛选条件：
WHERE deleted_at IS NULL
laravel已经为我们写好这部分逻辑了，在模型内引入如下trait：
namespace App;
use IlluminateDatabaseEloquentModel;
use IlluminateDatabaseEloquentSoftDeletes;
在类内引入trait，并手动指定修改器，也就是说deleted_at字段，我们使用 Carbon 进行实例化操作。
class Event extends Model {
use SoftDeletes;
protected $dates = ['created_at','deleted_at','started_at','updated_at'];}
保存这些更改之后，下次删除与此模型关联的记录时，deleted_at列将被设置为当前时间。任何设置deleted_at为日期时间值的记录，都不会包含在任何查询结果中，因此看起来已经被删除了。
这样操作非常有用，因为误删除的数据，随时可以通过设置 deleted_at = null 而恢复到正常的业务流程中，比如删除的用户，删除的订单，等等其他资源。
如果你在代码内要坚持查询全量数据，也包含软删除了的数据，那么代码这样写：
$events = Event::withTrashed()->get();
写在最后
本文我们有重温了laravel的模型软删除功能，通过创建迁移文件，修改数据库表，追加软删除字段。并在模型内引入 SoftDelete 代码片段引入软删除的程序功能。
Happy coding :-)
我是@程序员小助手，专注编程知识，圈子动态的IT领域原创作者
