在laravel中恢复软删除数据的方法主要有两种：对单个模型调用restore()方法，或通过withtrashed()查询后调用restore()批量恢复。1. 恢复单个模型：使用withtrashed()->find()获取软删除记录，再调用restore()将其deleted_at设为null；2. 批量恢复：通过withtrashed()结合where条件查询软删除数据，再调用restore()进行批量更新，返回受影响行数；3. 注意事项包括性能问题需分批处理、关联模型不会自动恢复需手动处理、唯一性约束可能引发冲突需提前检查，且复杂操作建议使用事务确保一致性。
在Laravel里，想把那些被“软删除”的数据找回来，其实就是那么几招：要么直接在某个模型实例上调用restore()方法，要么就是在查询的时候，先用withTrashed()把它们都捞出来，再跟着一个restore()。听起来简单，但里头还是有些门道的，尤其是在处理关联数据或者批量操作时，需要多留个心眼。
当你需要恢复Laravel中被软删除的记录时，核心操作围绕着restore()方法。这方法其实就是把模型实例的deleted_at字段设回null，并更新updated_at时间戳。
恢复单个模型实例：
这是最直接的方式。你首先需要通过某种方式找到那条被软删除的记录。注意，常规的find()或get()方法默认是不会查询到软删除记录的。你需要使用withTrashed()。
use App\Models\Post; // 假设你的模型是Post
// 找到一条被软删除的帖子
$post = Post::withTrashed()->find(1);
if ($post) {
$post->restore(); // 调用 restore() 方法
// 此时，$post 已经被恢复，deleted_at 字段变为 null
// 你可以检查 $post->trashed() 会返回 false
echo "帖子 ID: {$post->id} 已成功恢复。";
} else {
echo "未找到该帖子，或者它并未被软删除。";
}我个人觉得，这种方式在处理用户误删或单个数据回溯时特别顺手，直观且不容易出错。
恢复多条或批量模型实例：
如果你需要根据某个条件批量恢复数据，比如恢复某个用户所有被删除的评论，或者在某个时间段内被删除的所有文章，你可以在查询构建器上直接链式调用restore()。
use App\Models\Comment; // 假设你的模型是Comment
// 恢复用户ID为5的所有被软删除的评论
$affectedRows = Comment::withTrashed()
->where('user_id', 5)
->restore();
echo "成功恢复了 {$affectedRows} 条评论。";
// 恢复所有在特定日期之后被软删除的帖子
use App\Models\Article; // 假设你的模型是Article
$affectedArticles = Article::withTrashed()
->where('deleted_at', '>', '2023-01-01 00:00:00')
->restore();
echo "成功恢复了 {$affectedArticles} 篇文章。";这里值得注意的是，restore()方法在查询构建器上调用时，会返回受影响的行数。这对于批量操作后的反馈很有用。我经常用它来确认操作是否按预期执行，或者在日志中记录。
这真是个老生常谈但又不得不提的问题。在项目初期，很多人会纠结到底是用软删除还是直接硬删除。我的看法是，这取决于你的业务需求和数据敏感度。
软删除（Soft Deletes），顾名思义，它并没有真正从数据库中删除数据，只是给记录打上了一个“已删除”的标记（通常是deleted_at字段被填充）。这样做的好处显而易见：
然而，软删除也有其缺点：
withTrashed()方法，这在某些复杂查询中可能会稍微增加心智负担。email字段需要唯一。如果一个用户被软删除了，他的邮箱还在数据库里，那么新用户就不能注册这个邮箱。你可能需要针对性地处理唯一性约束，比如在唯一索引上加上where deleted_at IS NULL的条件，或者在应用层面做额外检查。硬删除（Hard Deletes）就是直接从数据库中移除记录。它的优点是：
deleted_at字段过滤，理论上查询更直接。但缺点也同样明显：数据一旦删除，就不可恢复。
我的建议是： 凡是涉及用户核心数据、交易记录、或者未来可能需要回溯的数据，无脑选择软删除。对于那些临时性、不重要、或者生成后就不再需要的数据（比如某些日志、缓存），硬删除更合适。这没有绝对的对错，关键在于理解各自的利弊，并结合具体业务场景做出最适合的决策。
批量恢复数据，听起来很酷，一行代码搞定几百上千条记录。但实际操作中，确实有些“坑”需要注意，否则可能会给你带来意想不到的麻烦。
1. 性能问题：
当你批量恢复大量数据时，比如几十万条，这会给数据库带来不小的压力。每次restore()操作都会触发数据库的UPDATE语句，如果并发量大，或者表上有复杂的索引和触发器，可能会导致数据库锁表，甚至拖慢整个系统。
解决方案： 考虑分批处理（chunking）。例如，每次只恢复1000条记录，然后暂停一下。或者在业务低峰期执行。
// 假设要恢复所有被软删除的订单
Order::withTrashed()
->whereNotNull('deleted_at') // 确保只处理被软删除的
->chunkById(1000, function ($orders) {
foreach ($orders as $order) {
$order->restore();
}
// 可以在这里加个 sleep(1) 稍微缓解数据库压力
});当然，如果你的Laravel版本够新，并且你确定不需要模型事件（比如restored事件），直接使用查询构建器的restore()会更高效，因为它只执行一条SQL语句。但如果你需要模型事件触发，那就得循环调用$model->restore()。这是个取舍。
2. 关联数据的一致性： 这是个大坑。你恢复了一条父级记录，但它的子级记录呢？如果子级记录也被软删除了，它们会自动恢复吗？答案通常是：不会。Laravel的软删除机制只作用于当前模型，不会自动级联到关联模型。
场景举例： 你恢复了一篇被软删除的文章，但文章下的评论如果也被软删除了，它们依然是软删除状态。用户看到文章了，却看不到评论。
解决方案： 你可能需要在恢复父级记录的同时，手动恢复其关联的子级记录。这通常需要在模型中定义好关系，然后在restore()之后或在自定义的恢复方法中处理。
class Post extends Model
{
use SoftDeletes;
public function comments()
{
return $this->hasMany(Comment::class);
}
// 自定义一个恢复方法，处理关联
public function restoreWithComments()
{
$this->restore(); // 恢复文章本身
$this->comments()->withTrashed()->restore(); // 恢复所有关联的评论
}
}
// 调用时
$post = Post::withTrashed()->find(1);
if ($post) {
$post->restoreWithComments();
}我个人建议，如果你的业务逻辑需要这种级联恢复，最好是把这个逻辑封装在模型方法里，或者专门的服务类里，这样既清晰又易于维护。
3. 唯一性约束冲突： 前面提过，如果你的表上有唯一性约束（比如邮箱、用户名），而软删除的记录中包含了与当前尝试插入或恢复的记录冲突的值，那么恢复操作会失败。
解决方案： 这通常需要在恢复前进行检查，或者在数据库层面调整唯一索引，使其忽略被软删除的记录（例如，在MySQL中，可以创建一个复合唯一索引，包含column和deleted_at，并允许deleted_at为NULL）。但后者比较复杂，也可能不是所有数据库都支持。更常见的做法是在应用层做预判，或者在恢复失败时捕获异常并处理。
try {
$user = User::withTrashed()->find(10);
if ($user) {
// 假设邮箱是唯一的
$existingUser = User::where('email', $user->email)->first();
if ($existingUser && $existingUser->id !== $user->id) {
// 如果存在相同邮箱且不是自身，说明会冲突
throw new \Exception("邮箱 {$user->email} 已被占用，无法恢复用户 ID: {$user->id}");
}
$user->restore();
echo "用户 ID: {$user->id} 已成功恢复。";
}
} catch (\Exception $e) {
echo "恢复失败: " . $e->getMessage();
}这种显式检查虽然增加了代码量，但在业务逻辑复杂时，能有效避免数据不一致和程序崩溃。
这是一个非常关键的问题，也是我前面提到的“坑”的延伸。理解这一点，对于维护数据完整性至关重要。
当你在Laravel中恢复一条软删除的父级记录时，默认情况下，其关联的子级记录并不会自动恢复。它们的deleted_at字段状态保持不变。这意味着：
子级记录如果未被软删除，则保持可见： 如果父级记录被软删除时，其关联的子级记录（比如文章的评论）并没有被软删除，那么在父级记录恢复后，这些子级记录依然是可见的，并且可以正常通过关系加载。
子级记录如果也被软删除，则保持不可见： 这是最常见也最容易让人困惑的情况。如果你在删除父级记录时，也级联地软删除了子级记录（例如，通过在父模型上监听deleting事件来手动软删除子模型，或者通过数据库触发器），那么在父级记录恢复后，这些子级记录依然是“软删除”状态，通过常规关系（如$post->comments）是无法加载出来的。你必须使用withTrashed()或onlyTrashed()来显式加载它们。
$post = Post::withTrashed()->find(1);
$post->restore(); // 文章恢复了
// 此时，如果你尝试 $post->comments，你将看不到任何评论，
// 因为关联的评论如果也被软删除，它们依然是软删除状态。
// 你需要这样做：
$comments = $post->comments()->withTrashed()->get();
foreach ($comments as $comment) {
if ($comment->trashed()) {
$comment->restore(); // 手动恢复每条评论
}
}解决方案和最佳实践：
明确的级联恢复逻辑： 如果你的业务场景需要父子级联恢复，请务必在代码中显式实现。我前面给出的restoreWithComments()就是一个很好的例子。你可以在父模型上定义一个方法，负责恢复自身以及所有相关的子模型。
考虑数据一致性策略： 在设计数据库和应用逻辑时，就要考虑“删除”和“恢复”操作对关联数据的影响。是父子同生共死（一起删除一起恢复），还是父死子活（父删除子保留，但通过关系不可见），或者父活子死（父恢复子依然删除）？这需要根据业务需求来决定。
使用事务： 在进行复杂的恢复操作，特别是涉及多个模型和关联模型时，务必将整个恢复过程包裹在数据库事务中。这样，如果中间有任何一步失败，你可以回滚所有操作，确保数据的一致性。
DB::transaction(function () use ($post) {
$post->restore();
$post->comments()->withTrashed()->restore();
// 甚至可以恢复更多层级的关联数据
});事务是数据库操作的“安全网”，在处理关键数据时，我几乎都会用到它。它能大大降低数据不一致的风险。
总而言之，Laravel的软删除机制提供了一个非常方便的起点，但它更多的是关于单个模型实例的“标记”与“取消标记”。对于更复杂的业务场景，特别是涉及多层级关联数据时，我们需要投入更多精力去设计和实现一套完整的“删除”与“恢复”策略，确保数据在任何状态下都能保持其应有的完整性和一致性。
以上就是如何在Laravel中使用软删除恢复的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
272
收藏
