PHP怎么实现Eloquent Attribute History States属性历史状态_Laravel状态回溯【技巧】-php教程-PHP中文网

eloquent 的 $casts 和访问器无法记录历史状态，因为它们仅在读取时运行、不触发写入，必须在 updated 事件中用 getchanges() 显式持久化变更，确保事务一致性并避免类型转换和批量更新陷阱。

php怎么实现eloquent attribute history states属性历史状态_laravel状态回溯【技巧】

为什么 Eloquent 的 `$casts` 和访问器无法记录历史状态

因为 Eloquent 的 getFooAttribute 访问器、$casts 或 getAttributeValue 都是运行时计算或转换，不触发数据库写入，也不保存快照。想回溯「某个字段在某次更新前的值」，必须在每次变更时显式持久化旧值——不能靠读取逻辑“反推”。

常见错误是试图用模型事件监听 saving 然后手动比对 $model->getOriginal('status')，但这个值在批量更新（如 update(['status' => 'done'])）中可能已被覆盖，导致漏存或误存。

务必在 saved 或 updated 事件中获取变更前后值，此时 $model->getOriginal() 和 $model->getAttributes() 才可靠
避免在 saving 中做历史写入：此时事务未提交，若后续失败会导致历史记录孤立
不要依赖 dirty() 判断字段是否变更——它不识别 null ⇄ ''、0 ⇄ '0' 这类 PHP 类型隐式转换差异

用 `updated` 事件 + `getChanges()` 安全捕获变更字段

getChanges() 返回的是本次更新中「真正被修改过的键值对」，且已过类型标准化（比如整数字段不会返回字符串），比手写 array_diff_assoc 更稳。

示例：为 Order 模型记录 status 变更历史：

// app/Models/Order.php
protected static function booted()
{
    static::updated(function ($order) {
        $changes = $order->getChanges();
        if (isset($changes['status'])) {
            \App\Models\OrderStatusHistory::create([
                'order_id' => $order->id,
                'old_status' => $order->getOriginal('status'),
                'new_status' => $changes['status'],
                'changed_at' => now(),
            ]);
        }
    });
}

getChanges() 只在 update()、save() 等明确变更操作后才有值；create() 不触发它
如果需支持批量更新（如 Order::whereIn(...)->update(...)），该事件不会触发——此时必须改用数据库触发器或应用层封装 updateMany() 方法
注意时间字段：用 now() 而非 $order->updated_at，后者可能被显式设置或软删除时间干扰

历史表设计要避开 Laravel 自增主键陷阱

用 id 自增主键查「某订单最近 3 条状态变更」会很慢，因为数据按插入时间物理无序。更合理的是联合索引 + 时间降序查询。

PHP 8.5.5

PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。

下载

推荐迁移结构：

Schema::create('order_status_histories', function (Blueprint $table) {
    $table->id(); // 仍保留，方便关联和调试
    $table->unsignedBigInteger('order_id');
    $table->string('old_status')->nullable();
    $table->string('new_status');
    $table->timestamp('changed_at')->useCurrent();
    
    $table->index(['order_id', 'changed_at']); // 关键：支持 order_id + 时间范围查询
});

别把 changed_at 设为 nullable：否则 ORDER BY changed_at DESC 会把 NULL 排最前，干扰最新状态获取
如果业务要求严格时序（比如并发更新），加数据库唯一约束 UNIQUE(order_id, changed_at) 并用 microtime(true) 补精度，避免时间戳重复
不建议用 UUID 主键：历史表写多读少，UUID 插入性能差，且无业务意义

查询历史时慎用 `with()` 预加载关联

直接 $order->statusHistories 是懒加载，N+1 问题明显；但盲目 with('statusHistories') 会一次性拉取全部历史，内存爆炸。

正确做法是按需分页或限制条数：

// 查单个订单最近 5 条状态变更
$order->load(['statusHistories' => function ($q) {
    $q->latest('changed_at')->limit(5);
}]);

// 或预加载时用子查询取每条订单的最新一条状态（Laravel 10+）
Order::withSubquery('latestStatus', OrderStatusHistory::select('new_status')
    ->whereColumn('order_id', 'orders.id')
    ->latest('changed_at')
    ->limit(1)
)->get();