ThinkPHP模型延迟写入需手动调用delayData()或设置writeDelay配置，仅对同一模型同一批数据生效，通过合并save()为单次批量SQL执行，触发时机包括新主键、flush()或脚本结束。
ThinkPHP模型延迟写入怎么开
延迟写入不是默认开启的，得手动调用 delayData() 或设置 writeDelay 配置。它本质是把多次 save() 合并成一次 SQL 批量更新，但只对同一模型、同一批数据生效。
- 必须在模型实例上调用，
Db::name('user')->delayData(true)无效，得用UserModel::delayData(true) - 开启后，后续的
save()不会立刻执行 SQL，而是暂存到内存；触发时机是：下次调用save()传不同主键、显式调用flush()、或脚本结束 - 注意事务内慎用——延迟写入和事务提交顺序不一致时，可能丢数据或报错
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active - 示例：
$user = new UserModel(); $user->delayData(true); $user->data(['id' => 1, 'status' => 1])->save(); $user->data(['id' => 2, 'status' => 2])->save(); // 这里还没发 SQL $user->flush(); // 此刻才发出一条 UPDATE ... WHERE id IN (1,2)
ThinkPHP批量更新为什么不用updateAll
updateAll() 看似简单，但它绕过模型事件、验证、自动时间戳、甚至字段类型转换，容易导致数据不一致。比如你有 status 字段是枚举类型，模型里定义了 type => 'tinyint'，直接 updateAll 传字符串就会写入失败或被截断。
- 真正安全的批量更新，应该走模型的
saveAll()+ 延迟写入，或用batchUpdate()（6.1+） -
updateAll()只适合后台脚本、数据迁移等“不走业务逻辑”的场景；线上接口中混用，后期加个钩子或日志就漏掉 - 性能上，
updateAll()单条 SQL 是快，但丢了软删除判断、事件回调、缓存清理这些隐性保障，调试成本远高于那几十毫秒
ThinkPHP延迟写入失效的常见原因
写了 delayData(true) 却还是每条都发 SQL？大概率是这几个点没对上。
- 主键值不统一：延迟写入只合并「相同主键字段」的数据，比如你用
id当主键，但某次传的是user_id，它就当新批次处理 - 数据结构不一致：两次
save()传的字段名不同（比如第一次有name，第二次多出email），框架会认为这不是同一批可合并操作 - 中间穿插了查询：只要在延迟期间调用了
find()、select()等读操作，部分版本会自动 flush，避免脏读 - PHP-FPM 模式下，对象生命周期短，如果延迟写入跨请求（比如放 session 或 cache 里），完全不生效——它只在当前模型实例生命周期内有效
ThinkPHP 6.0 和 6.1 的 batchUpdate 差在哪
batchUpdate() 是 6.1 新增的官方批量更新方法，比手写 delayData() 更稳，但参数和行为有明显变化。
立即学习“PHP免费学习笔记（深入）”；
- 6.0 没这个方法，别在 6.0 项目里搜
batchUpdate，会报Call to undefined method think\Model::batchUpdate() - 6.1 要求数据必须是二维数组，且每项必须含主键字段（如
['id' => 1, 'name' => 'a']），不能传一维关联数组 - 它默认跳过验证和事件，但可通过第二个参数开启：
batchUpdate($data, ['force' => true])，这时会触发before_write事件，但不走validate - 性能上比
delayData() + save()稍低一点（因为要预处理字段映射），但胜在语义明确、不易误用
