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