TP6.0 使用模型观察者自动写入更新人及时间戳【Audit】

先抛出第一个结论：在 TP6.0 中处理“自动写入更新人 + 时间戳”这类审计需求，最稳妥的方案不是模型观察者（Observer），而是模型事件（Model Events）。原因很简单：Observer 在 TP6 里的定位已经发生了一些变化，它更像一个轻量的事件封装，而非 Lara vel 那样贯穿生命周期的可靠监听器。更重要的是，批量更新、软删除、关联保存等高频场景，Observer 要么覆盖不到，要么表现不稳定。

为什么模型观察者不是首选？

如果你之前从 Lara vel 转过来，可能会下意识地想用 Observer——但这里有个关键区别：TP6 的 Observer 默认并没有注册好完整的生命周期监听。换句话说，Db::table()->update()、Model::destroy()、Model::update() 这些操作，Observer 是“视而不见”的。更棘手的是，它很难可靠地区分 insert、update、delete 操作类型，也没有机制处理事务回滚后的日志清理。这种“先天不足”，直接导致了审计日志容易失真。

推荐方案：before_write + after_write 事件

这才是 TP6 官方推荐、且能覆盖所有写入路径的稳定方案。核心思路是在模型中直接定义事件监听逻辑：

• before_write：在数据写入前介入，此时可以获取到待写入的数据集，适合注入 operator_id、IP、user_agent 等审计字段。
• after_write：确认写入成功后再触发，适合将审计记录写入独立的 AuditLog 表——这样即使主表事务回滚，日志也不会被连带清理。

来看一个 User 模型的具体示例：

protected static function init(){
    self::beforeWrite(function($model) {
        // 判断本次是新增还是更新
        $isInsert = empty($model->id) || !$model->exists();
        $model->update_time = time(); // 显式赋值，避免 autoWriteTimestamp 干扰
        $model->operator_id = context_get_user_id() ?: 0; // 从 Token/请求上下文取，而非 session
        $model->operator_ip  = request()->ip();
    });

    self::afterWrite(function($model, $result) {
        if ($result) {
            app\model\AuditLog::create([
                'table_name'   => 'user',
                'record_id'    => $model->id,
                'action'       => $model->exists() ? 'update' : 'insert',
                'operator_id'  => $model->operator_id,
                'ip'           => $model->operator_ip,
                'created_at'   => date('Y-m-d H:i:s'),
            ]);
        }
    });
}

审计日志表必须独立建模，并严格禁用自动时间戳

这里有一个容易踩的坑：AuditLog 模型一定要和主模型完全隔离。核心要点有三点：

• 显式关闭自动时间戳写入：protected $autoWriteTimestamp = false;
• 所有时间字段坚持用 date('Y-m-d H:i:s') 或 time() 手动赋值，不依赖模型配置。
• operator_id、ip 等字段不要设成 $readonly 或 $auto，全部显式传入，避免循环触发或类型冲突。

另外，日志写入建议套一层 try-catch，即使失败也不影响主业务流程——毕竟审计只是辅助，不能拖垮核心服务。

动态控制：何时跳过审计字段写入？

并不是所有更新都需要走审计流程。比如“仅更新阅读数”这类场景，就需要跳过审计字段的注入。可以这样处理：

• 临时关闭时间戳：$user->isAutoWriteTimestamp(false)->sa ve();
• 在 before_write 中判断字段是否发生实质性变更：如果只有 read 字段变化，就不设置 operator_id。
• 批量操作时，建议用 foreach 单条处理并注入上下文，这样能确保每个操作都带有正确的操作人信息，不会丢失。

说到底，实现审计功能的关键不在于“用什么模式”，而在于能否稳定、全面地捕获每一次数据变更。在 TP6.0 里，模型事件 + 独立日志表这套组合，是目前最经得起考验的实践方案。