Laravel如何做模型软删除恢复记录审计_Laravel记录谁在何时恢复【操作】-Laravel-PHP中文网

应通过事务封装的专用服务方法（如restoreWithAudit）在restore前写入restored_by和restored_at，避免依赖模型事件；审计数据宜单独建表（如users_restores），并用事务确保一致性。

laravel如何做模型软删除恢复记录审计_laravel记录谁在何时恢复【操作】

软删除记录被恢复时如何捕获操作人和时间

软删除的模型恢复（restore()）默认不触发任何事件，也不会自动记录谁执行了恢复、何时执行。Laravel 的 restoring 和 restored 事件确实存在，但它们只在调用 restore() 时触发，**不会自动携带当前用户信息或时间戳**——这些必须手动注入。

常见错误现象：restored 事件回调里直接读 auth()->user()，结果在队列、命令行或 API 无 session 场景下返回 null；或者把时间写死成 now()，但实际恢复可能发生在事务中，时间点不准确。

必须在调用 restore() 前明确传入操作人 ID（如 $userId = auth()->id()），避免在事件里反查
推荐在业务逻辑层统一处理，而不是依赖模型事件自动推断上下文
如果走 Eloquent 批量恢复（Model::withTrashed()->where(...)->restore()），事件仍会逐条触发，但操作人需全局绑定（如通过请求中间件存到 static 变量，慎用）

audit\_restored 字段怎么加才不影响查询性能

新增字段用于记录恢复操作人（restored_by）和恢复时间（restored_at）是常见做法，但直接加到原表会拖慢所有软删除相关查询（因为 deleted_at IS NULL 索引无法覆盖新增字段）。

使用场景：需要频繁筛选“已被恢复的记录”或“某人恢复的所有记录”，同时又要保持主表查询速度。

restored_at 必须加索引，否则 whereNotNull('restored_at') 会全表扫描
不要用 JSON 字段存操作人信息（如 restored_meta），会导致无法高效 join 或 where 查询
如果恢复行为极少（比如每月不到 10 次），可不加索引；但只要涉及后台审计列表页，就必须为 restored_by 和 restored_at 单独建复合索引：INDEX (restored_at, restored_by)

restore() 调用前如何确保 restored\_by 不为空

直接在模型的 restored 事件里写 $model->restored_by = auth()->id() 是错的：事件触发时模型已从数据库加载，save() 会额外发起一次 update，且不保证原子性（比如并发恢复同一条记录）。

Laravel Cloud

Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。

下载

正确做法是把恢复逻辑收口到一个服务方法里，强制校验上下文：

public function restoreWithAudit(Model $model, int $userId): bool
{
    if (!$model->trashed()) {
        return false;
    }

    return DB::transaction(function () use ($model, $userId) {
        $model->restored_by = $userId;
        $model->restored_at = now();
        return $model->restore();
    });
}

必须用 DB::transaction() 包裹，防止 restore() 成功但 audit 字段写入失败
不能依赖模型的 fill() 或 update() 单独更新 audit 字段——restore() 本身会重置 deleted_at，但不会 touch 其他字段
命令行场景下 $userId 应由调用方显式传入（如 php artisan model:restore 123 --by=1），而非硬编码 auth()

审计日志要不要单独建表而不是塞在原模型里

把 restored_by 和 restored_at 加到原模型表里看似简单，但很快会遇到扩展瓶颈：比如要记录恢复原因、IP、UA、关联变更字段等，原表就变得臃肿且难以维护。

性能与兼容性影响：单表加字段对小项目够用；但一旦开启多租户、分库分表或需要对接审计系统，就必须解耦。

审计表命名建议用 model_name_restores（如 users_restores），字段至少包含：user_id（操作人）、model_type、model_id、restored_at、ip_address、reason
用 Laravel 的 MorphTo 关联可复用审计表，但要注意：软删除模型恢复时，model_id 对应的是已存在的记录，不是新创建的
别在 restored 事件里直接 new AuditRecord() → save()，容易因事务回滚导致审计数据残留；应改用 DB::transaction() 统一提交