应通过事务封装的专用服务方法（如restoreWithAudit）在restore前写入restored_by和restored_at，避免依赖模型事件；审计数据宜单独建表（如users_restores），并用事务确保一致性。
软删除记录被恢复时如何捕获操作人和时间
软删除的模型恢复（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，且不保证原子性（比如并发恢复同一条记录）。
正确做法是把恢复逻辑收口到一个服务方法里，强制校验上下文：
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()统一提交
真正麻烦的不是加字段或建表，而是恢复操作常发生在紧急修复场景下——没人记得补 audit，也没人验证是否真写了日志。最稳妥的方式，是把恢复入口全部收归一个 Service 类，并在构造函数里强制 require $userId 和 $reason 参数。
