首先给出一个核心结论：在 ThinkPHP 6.0 中，要实现“自动写入更新人 + 时间戳”这类审计追踪需求，最稳妥的方案并非模型观察者（Observer），而是模型事件（Model Events）。原因在于：TP6 对 Observer 的定位已经发生了实质性变化，它更像一个轻量的事件封装，而非像 Laravel 那样贯穿整个生命周期的可靠监听器。更关键的是，批量更新、软删除、关联保存等高频操作场景下，Observer 要么无法覆盖，要么表现不够稳定，容易导致审计数据缺失或错误。
为什么模型观察者不是首选方案？
如果你之前从 Laravel 迁移过来，可能会下意识地尝试使用 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)->save(); - 在 before_write 中判断字段是否发生实质性变更：如果只有
read字段变化，就不设置operator_id。 - 批量操作时，建议用
foreach单条处理并注入上下文，这样能确保每个操作都带有正确的操作人信息，不会丢失。
说到底，实现审计功能的关键不在于“用什么模式”，而在于能否稳定、全面地捕获每一次数据变更。在 TP6.0 里，模型事件 + 独立日志表这套组合，是目前最经得起考验的实践方案。
