ThinkPHP模型回调仅作用于模型方法（如save、delete），不捕获Db类原生操作；saveAll()中beforeWrite仅触发一次，非逐条；afterWrite中应通过getData()获取主键值，避免直接访问属性。
ThinkPHP 模型本身不提供「监听任意数据库操作」的能力，比如你无法用一个钩子捕获所有 Db::table()->where()->update() 或原生 SQL 执行。所谓「模型回调」只作用于该模型实例的 save()、create()、delete() 等方法，且仅限于通过模型触发的操作。
哪些模型方法会触发 beforeWrite / afterWrite
只有走模型写入流程的方法才触发事件，包括：
-
save()（单条新增或更新） -
saveAll()（批量保存，但注意：beforeWrite不会为每条记录单独触发，它只在批量入口执行一次） -
create()（已废弃，但若还在用，也会触发） -
delete()和destroy()（触发beforeDelete/afterDelete）
不会触发的场景包括：
-
Db::name('user')->update([...])—— 绕过模型，无任何回调 -
$model->data([...])->isUpdate(true)->save()但字段被设为readonly——beforeWrite仍会执行，但写入字段可能被过滤 - 关联模型的自动保存（如
$user->posts()->save(...)）—— 只触发关联模型自身的回调，不触发主模型回调
为什么 afterWrite 里查不到刚写入的 ID（自增主键）
因为 afterWrite 触发时，数据已写入，但模型实例的主键属性可能还没同步回来。常见错误是直接读 $this->id 得到 null 或旧值。
立即学习“PHP免费学习笔记（深入）”；
正确做法是：
- 用
$this->getPk()获取主键名，再用$this->getData($pk)读取； - 或更稳妥地：显式调用
$this->getOrigin($pk)（如果主键是自增且未手动赋值）； - 避免在
afterWrite中再次调用save()，容易引发递归或事务异常。
示例：
public function afterWrite()
{
$id = $this->getData('id'); // ✅ 推荐，getData 返回当前写入后的值
// $id = $this->id; // ❌ 不可靠，可能还是 null
if ($id) {
// 记录日志或触发异步任务
Log::write("User created: {$id}");
}
}
如何让回调兼容批量操作（saveAll）
saveAll() 默认不逐条触发 beforeWrite，这是设计使然，不是 bug。若你确实需要每条都校验或填充，有两个选择：
- 改用循环 + 单条
save()：性能略低，但逻辑完全可控； - 在
saveAll()前手动预处理数据数组，比如统一调用setCreateTimeAttr或补全用户 ID； - 重写
saveAll()方法，在内部对每条数据 new 模型实例并调用save()（不推荐，破坏封装且易出错）。
注意：saveAll() 的返回值是结果数组，不是模型实例集合，所以不能靠它链式调用回调逻辑。
回调中调用服务类要注意容器绑定时机
在 beforeWrite 或 afterWrite 里调用 app('UserService') 是安全的，但如果你的服务依赖 Request 或 Session，得确认它们已在当前生命周期中初始化。常见失败现象是 Call to a member function user() on null。
验证方式：
- 在回调开头加
if (!app('request')->isCli()) { ... }避免命令行场景报错； - 不要在模型静态方法里调用
app()，应放到实例方法中； - 若服务需跨请求上下文（如队列任务中），不能依赖
app('request')，得把必要参数（如user_id）提前传入模型或通过属性携带。
真正容易被忽略的点是：回调函数的执行时机紧贴数据库事务，一旦你在里面抛异常或 return false，整个事务会回滚 —— 这既是保护，也是风险。别在回调里做耗时 IO 或未兜底的远程调用。
