Eloquent 无原生属性快照功能，实际需通过 updating 事件手动捕获新旧值或借助事件溯源包实现；直接调用 snapshotStates 等方法会报错。
什么是 Eloquent Attribute Snapshot States 的实际用途
Eloquent 本身不提供原生的“属性快照”或“状态历史”功能。所谓 Attribute Snapshot States，其实是事件溯源（Event Sourcing）中一个常见需求：记录模型某次变更前后关键字段的值，用于审计、回滚、差异比对或触发下游逻辑。Laravel 没有内置 snapshot_states 这样的方法或配置项，强行套用这个命名容易误以为是框架特性，结果在文档里找不到对应 API。
真实可行路径只有两条：
- 在模型的
updating/saving事件中手动捕获旧值与新值 - 借助第三方包（如
spatie/laravel-event-sourcing）构建完整事件流，其中“快照”是可选策略而非默认行为
直接试图调用 $model->snapshotStates() 或配置 protected $snapshot_states = [...] 会报错——因为这些不是 Laravel 或 Eloquent 的有效成员。
如何在 updating 事件中安全获取属性变更前后的值
Eloquent 的 updating 事件触发时，模型实例已加载原始数据，$model->getOriginal('field') 可读取数据库中的旧值，$model->getAttribute('field') 是当前待写入的新值。这是最轻量、无依赖的实现方式。
立即学习“PHP免费学习笔记（深入）”；
注意几个关键点：
- 必须在事件监听器或模型观察者中操作，不能在
save()调用后才去取getOriginal()，否则旧值已被覆盖 - 对于批量更新（
Model::where(...)->update(...)），Eloquent 不触发模型事件，此方案完全失效 -
getOriginal()返回的是从数据库加载时的值，如果中间手动调过$model->setRawAttributes()，可能不准
示例片段（放在 booted() 中）：
static::updating(function ($model) {
$changed = [];
foreach (['name', 'status', 'amount'] as $attr) {
$old = $model->getOriginal($attr);
$new = $model->getAttribute($attr);
if ($old !== $new) {
$changed[$attr] = ['from' => $old, 'to' => $new];
}
}
if (!empty($changed)) {
// 写入 snapshot_logs 表，或 dispatch(SnapshotRecorded::class)
}
});为什么不要用 model cast + json 存快照到主表字段
有人尝试在模型里加个 snapshot 字段，类型为 json，然后每次保存前序列化整个 $model->getAttributes()。这看似简单，但埋了三个坑：
- 主表体积膨胀快：尤其当模型字段多、文本长时，一次快照可能达数 KB，几十万条记录后索引变慢、备份耗时剧增
- 查询无法走索引：想查“所有 status 从 draft → published 的记录”，得全表 JSON 解析，MySQL 5.7+ 虽支持
JSON_CONTAINS，但性能远不如普通字段查询 - 状态语义丢失：快照只存值，不存“谁在什么时间因什么操作改的”，缺乏事件溯源所需的上下文（比如 HTTP 请求 ID、用户 ID、来源 IP）
真正需要事件溯源时，应该把状态变更拆成明确的领域事件（如 UserStatusChanged），再由专门的快照服务（如定期聚合最新状态）来优化读取。
spatie/laravel-event-sourcing 里 snapshot 是怎么工作的
该包的 Snapshot 功能本质是：当事件流长度超过阈值（默认 1000 条），就将当前聚合根状态持久化为一条快照记录，后续重放事件时先加载快照，再从快照之后的事件继续播。它不记录每次属性变化，而是做“状态压缩”。
关键事实：
- 快照只针对聚合根（Aggregate Root），不是单个 Eloquent 模型
- 快照表（
snapshots）结构固定：aggregate_type、aggregate_id、snapshot（序列化后的状态数组）、version - 启用快照需显式调用
$aggregateRoot->persistSnapshotsAfter(1000)，不会自动触发 - 它不替代属性级变更日志，而是解决事件重放性能问题
如果你只是想看“这条订单的 price 字段被改过几次”，用这个包反而绕远路；但若系统已有完整事件流且读多写少，快照能明显降低重建状态的开销。
属性快照这件事，没有银弹。Eloquent 层能做的只有精准抓取变更字段，而真正的状态管理必须结合业务场景决定粒度和存储位置——别让“快照”二字模糊了你到底要解决审计、回滚，还是性能问题。
