Laravel模型属性变更记录与审计表差异日志详解

在 Lara vel 模型保存前获取旧值和新值，唯一可靠方式是使用 $model->getOriginal() 获取数据库原始值，但需确保模型已从数据库加载且未被 refresh 或手动修改原始快照；新建模型时 exists === false，JSON 字段需 json_decode() 后比对；建议用白名单逐字段对比并标准化 JSON 存储。

如何在 Lara vel 模型保存前拿到旧值和新值

想在 Lara vel 的 updating 或 sa ving 事件里准确捕获数据变化？$model->getOriginal() 几乎是唯一可靠的途径。但这里有个关键前提：它只在模型已从数据库加载（换句话说，不是新建记录）且其内部原始快照未被 refresh() 或手动修改过时，给出的结果才是准确的。

一个常见的误区是直接拿 $model->getAttributes() 来做对比，结果发现所谓的“旧值”其实是上一次 set 操作后的值，并非数据库里的真实状态。这个坑在批量更新或者中间件偷偷修改了属性后，尤其隐蔽。

• $model->isDirty() 可以用来判断哪些字段发生了变动，但它不提供具体的旧值，需要配合 getOriginal('field') 来使用。
• 如果模型是通过 findOrNew() 或构造函数新建的，getOriginal() 会返回一个空数组。这时候，先判断 exists === false 再决定是否跳过审计逻辑，是个稳妥的做法。
• 对于 JSON 或序列化字段（比如定义了 $casts = ['meta' => 'array']），getOriginal() 返回的是原始的 JSON 字符串。必须先用 json_decode() 处理，再进行比对，否则浅层比较永远会认为它们不相等。

Lara vel 用 diffAttributes() 做差异提取容易漏字段

diffAttributes() 这个方法看起来方便，但它仅仅是比较当前属性数组和原始属性数组的键值对。以下几种情况它可能处理不了：

• 数据库默认值字段：假设 status 字段默认是 'draft'。插入记录时如果没设置值，getOriginal() 里就不会有这个键，diff 就会忽略它。但从业务角度看，你可能需要记录这个“从无到有”的默认值变化。
• 属性被手动移除：使用 fill() 批量赋值后，如果在调用 sa ve() 前又执行了 unset($model->xxx)，那么这个字段就不会出现在 getAttributes() 里，但 getOriginal() 里还有。这时 diff 会误以为该字段被“删除”了。
• 软删除的语义：当软删除字段 deleted_at 被 delete() 方法触发时，getOriginal('deleted_at') 是 null，新值是时间戳，diff 能正确捕获。但问题来了：当模型被 restore() 恢复时，deleted_at 又从时间戳变回了 null。此时 diff 显示的是“从时间戳 → null”，而业务语义其实是“恢复记录”，并非简单的“清空字段”。

因此，更建议的做法是自己编写一个最小化的差异对比工具函数。显式声明一个需要审计的字段白名单，然后逐个检查 isset($original[$key]) 和 array_key_exists($key, $original)，避免过度依赖框架的自动推导逻辑。

审计日志存入数据库时，json 字段 vs text 字段的实际影响

选择 MySQL 存储差异日志时，别为了省事把所有内容都塞进 text 字段。虽然 json 类型支持索引和丰富的查询函数（比如 JSON_CONTAINS），但在 Lara vel 8+ 版本中，默认将数组转换为 json 字段时，会进行强制格式化（比如添加空格、对键进行排序）。这会导致两次完全相同的变更，最终生成的 JSON 字符串却不一致，无法直接用 = 操作符来查询重复的日志。

• 如果决定用 json 字段存储 changes，务必在数据入库前，使用 json_encode($diff, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) 进行标准化处理，并且不要添加 JSON_PRETTY_PRINT 选项。
• PostgreSQL 的 jsonb 类型没有这个格式化问题，但要注意，Lara vel 的 whereJsonContains() 方法在 PostgreSQL 上实际执行的是表达式函数，可能无法有效利用索引。如果对查询性能有较高要求，还是考虑将变更拆分成单独的字段（例如 changed_field, old_value, new_value）更靠谱。
• 审计表的主键不建议使用自增 ID，改用 ULID 或 UUID 是更好的选择。这可以避免在高并发场景下，尤其是配合队列异步写入日志时，日志的记录顺序与实际事件发生顺序产生错乱。

监听 sa ving 事件写审计日志，为什么有时没生效

这个问题最常踩的坑是：在 AppServiceProvider::boot() 方法里使用类似 User::sa ving(...) 的语法绑定事件。如果模型类还没有被自动加载，Lara vel 既不会报错，也不会触发事件——因为事件绑定发生在类定义之前。

• 正确的做法有两种：一是在模型类内部使用 static::sa ving() 方法注册事件；二是在 EventServiceProvider 的 $listen 属性数组中配置，例如 'eloquent.sa ving: App\Listeners\LogModelChange'。
• 如果审计逻辑中需要执行其他 Eloquent 操作（比如查询关联的用户姓名），务必小心不要在事务中嵌套事务，否则可能引发死锁。可以用 DB::transactionLevel() === 0 来判断当前是否已在事务中。
• 绝对不要在事件监听器里抛出 (throw) 异常，这会导致整个模型保存操作失败。审计逻辑失败时，应该静默地将错误记录到专用的日志文件（如 storage/logs/audit-fail.log），确保不影响主业务流程。

说到底，实现审计日志功能，真正的挑战从来不是“如何记录”，而是如何确保“每次变更都记录、只记录一次、并且不拖慢主请求的响应速度”。异步队列处理、延迟批量写入、配合失败重试机制，这才是生产环境下的标准配置。同步写入日志，通常只适合在开发阶段做快速验证。