Laravel模型快照需手动实现，核心是明确变更时机：保存前用updating事件+getChanges()，事后存档需设计快照表；对比用getAttributes()避免accessor干扰，JSON字段需标准化；wasChanged()仅在updating中有效，批量更新需DB监听；存储优先单独字段而非JSON以保障查询性能。
怎么用 Laravel 模型快照记录数据变更
Laravel 本身不内置模型快照功能，得靠第三方包或手写逻辑。最常用的是 spatie/laravel-model-states 或更轻量的 venturecraft/revisionable，但后者已多年未维护；目前推荐用 spatie/laravel-activitylog 配合手动 diff，或者直接用 Eloquent 的 getOriginal() 和 getChanges() 做实时比对。
关键不是“装哪个包”，而是明确你要对比的时机：是保存前校验？还是事后查历史？前者用 saved 或 updating 事件 + getChanges() 就够；后者必须落库存档，得设计快照表（比如 model_snapshots），字段至少含 model_type、model_id、original（JSON）、changed（JSON）、user_id。
-
getChanges()只返回「本次更新中被修改的字段」，且仅在saving/updating事件里有效；saved事件里它已为空 - 别依赖
wasChanged('field')判断字段是否真有语义变化——比如字符串前后空格不同、数字 0 和字符串 '0'，它可能识别不出 - 如果模型用了
casts（如'status' => 'boolean'），getOriginal()返回的是转换后的值，不是原始数据库值；要精确对比，得从$model->getAttributes()和$model->getOriginal()手动取原始数组再比较
Laravel 中 diff 两个模型实例的字段差异
没有现成的 diff() 方法，但可以用集合操作快速实现。核心思路是把两个模型的属性转成关联数组，再用 diff_assoc() 或手动遍历比对。
注意：Eloquent 模型的 toArray() 会触发访问器（accessors），可能污染比对结果；敏感场景建议用 $model->getAttributes() 直接拿底层属性值。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 避免直接
array_diff_assoc($a->toArray(), $b->toArray())—— 它不处理 null / '' / 0 的类型差异，也不递归比较嵌套数组（比如 JSON 字段） - 简单安全的做法：
$aAttrs = $a->getAttributes();<br>$bAttrs = $b->getAttributes();<br>$diff = [];<br>foreach (array_keys($aAttrs + $bAttrs) as $key) {<br> if (!array_key_exists($key, $aAttrs) || !array_key_exists($key, $bAttrs) || $aAttrs[$key] !== $bAttrs[$key]) {<br> $diff[$key] = [$aAttrs[$key] ?? null, $bAttrs[$key] ?? null];<br> }<br>} - 如果字段含 JSON 类型（如
meta），记得用json_encode($val, JSON_UNESCAPED_UNICODE | JSON_PARTIAL_OUTPUT_ON_ERROR)标准化后再比，否则换行、空格、键序都会导致误判
为什么 model->wasChanged() 有时不生效
这个方法只在模型生命周期的特定阶段有效：它依赖内部标记 $this->changes 数组，该数组仅在 syncChanges() 被调用后填充（通常发生在 fill()、update() 或赋值时）。一旦模型进入 saved 状态，$this->changes 就被清空。
- 在
saved事件回调里调wasChanged()总是返回false—— 此时得提前在updating事件里把差异存到临时属性，比如$model->dirtySnapshot = $model->getChanges() - 批量更新（
Model::where(...)->update(...)）完全绕过模型事件和wasChanged()，这种场景必须用查询日志或 DB 监听（如DB::listen()）捕获原始 SQL - 使用
forceFill()会跳过fillable检查，也跳过变更追踪 ——wasChanged()对它无效
快照存储选 JSON 字段还是单独字段
MySQL 5.7+ / PostgreSQL 支持 JSON 类型，开发省事，但查起来费劲。比如想查「所有 status 从 draft 变为 published 的快照」，JSON 字段得用 JSON_EXTRACT 或 -> 操作符，索引支持弱、性能差；而拆成 old_status、new_status 字段，能加联合索引、支持高效 where 查询。
- 如果差异字段固定且不多（如只关心
title、price、status），优先建单独字段，加INDEX(old_status, new_status)后查变更趋势极快 - 如果模型字段常变、或需完整保留任意字段（比如 CMS 的自定义字段），才用 JSON 存整个
original和changes；但务必在应用层做 schema 兼容处理——字段删了，旧快照里的 key 还在，解析时得防Undefined index - 别把快照表和主表放同一数据库还用 MyISAM 引擎——事务不一致风险高；至少用 InnoDB，并确保快照插入和主模型更新在同一个事务里（用
DB::transaction()包住）
真正难的不是记下差异，而是定义清楚「什么算一次有效变更」：是只要字段值不同就记，还是过滤掉无业务意义的修改（比如更新时间戳、浏览数）？这个边界得由业务规则决定，代码只能执行，不能替你判断。
