Laravel Auditing 软删除行为配置的深度解析

软删除审计的现状分析

在 Laravel Auditing 项目中，关于软删除操作的审计行为一直存在一些争议。当前实现中，当模型执行软删除时，审计系统会记录所有字段的变更情况，而不仅仅是 deleted_at 字段的变化。这种设计虽然提供了完整的数据变更历史，但在某些业务场景下可能显得过于冗余。

核心问题剖析

许多开发者期望能够通过配置选项来控制软删除时的审计行为：

• 当配置为 true 时，仅记录 deleted_at 字段的变化
• 当配置为 false 时，保持当前行为，记录所有字段变更

这种需求源于对审计日志精简化的追求，特别是在高频软删除操作的系统中，减少不必要的审计记录可以显著降低存储压力。

现有解决方案评估

目前项目中有几种可行的解决方案：

1. 全局配置法：通过修改 config/audit.php 中的 timestamps 选项，但这只能控制时间戳的审计行为，无法精确控制软删除时的字段记录。

2. transformAudit 方法：在模型中使用 transformAudit 方法进行自定义处理。这种方法灵活但需要在每个模型中实现，维护成本较高。

public function transformAudit(array $data): array
{
    if ($this->auditEvent === 'deleted' && in_array(SoftDeletes::class, class_uses(get_class($this)))) {
        $data['old_values'] = [];
        $data['new_values'] = [];
    }
    return $data;
}

3. 抽象基类法：创建一个继承自 Auditable 的抽象基类，在其中实现统一的审计逻辑，所有模型再继承这个基类。这种方法既保持了灵活性又减少了重复代码。

技术实现建议

对于希望实现配置化软删除审计的开发者，可以考虑以下实现路径：

1. 扩展配置项：在 config/audit.php 中添加 softdelete_audit 选项，默认为 false 保持向后兼容。

2. 修改审计逻辑：在核心审计逻辑中，当检测到软删除操作时，检查该配置项决定是否过滤非 deleted_at 字段。

3. 事件监听方案：通过监听模型的软删除事件，在事件处理器中根据配置决定审计行为。

最佳实践推荐

对于大多数项目，建议采用抽象基类的方式统一处理软删除审计。这种方法具有以下优势：

• 保持代码一致性
• 便于后期维护
• 可以根据项目需求灵活调整
• 不影响框架核心功能

未来展望

随着 Laravel Auditing 项目的发展，期待官方能够提供更细粒度的审计控制选项，使开发者能够更灵活地配置各种操作类型的审计行为，包括但不限于软删除操作。这将大大提升框架在不同业务场景下的适用性。