ThinkPHP模型不支持真正延迟写入，所谓“延迟”仅是暂存数据至对象属性，需显式调用save()才执行SQL；批量操作应优先使用Db::table()或insertAll()/updateAll()，并注意主键、字段一致性及事务安全。
延迟写入在 ThinkPHP 模型里怎么开、怎么用
ThinkPHP 的 delayed 写入不是全局开关，而是模型实例级行为，必须显式调用 save() 时传参或提前设置 ->isUpdate(false) + ->save(['delay' => true]) 才生效。官方文档里写的 ->delay(true) 方法只存在于部分旧版本（如 6.0.8 之前），6.0.12+ 已移除，直接调用会报 Call to undefined method think\Model::delay()。
正确做法是：用 Db::table() 替代模型操作，或改用事务 + 批量插入模拟延迟效果。模型层本身不支持真正意义上的“延迟提交”，所谓“延迟”只是把数据暂存在对象属性里，不触发 SQL，直到你调用 save() 或 update()。
-
$user = new User(); $user->name = 'a'; $user->email = 'a@b.c';—— 此时没任何 SQL -
$user->save();—— 此刻才 INSERT，无法再“撤回”或合并 - 想攒几条一起写？得自己收集数据，最后用
User::insertAll($dataList)
批量更新为什么不能直接用 where()->update()？
ThinkPHP 的 where()->update() 看似方便，但底层是单条 SQL 的 UPDATE ... SET ... WHERE ...，它只能把所有匹配记录设成同一组值。比如 User::where('id', 'in', [1,2,3])->update(['status' => 1]) 没问题；但如果你要给 ID=1 设 score=85、ID=2 设 score=92，这个方法完全无能为力。
常见错误是试图传二维数组：->update([['id'=>1,'score'=>85], ['id'=>2,'score'=>92]])，这会直接触发 Array to string conversion 警告，因为 update() 只接受一维关联数组。
- 真正需要差异化更新，必须用
Db::execute()拼写CASE WHEN语句 - 或用循环 +
save()，但性能差，且无事务保护时容易部分失败 - 更稳妥的是先查出主键和待更新字段，用
foreach构造updateAll()所需格式，再调用User::updateAll($data, 'id')
updateAll() 和 insertAll() 的坑在哪
updateAll() 不是模型方法，是 Query 类的静态方法，调用时必须指定主键字段名作为第二个参数，否则会报 Undefined index: id（即使你的主键真是 id）。它要求数据数组的每项都含该主键值，且结构必须严格一致——不能有的带 create_time、有的不带。
insertAll() 同样敏感：字段名必须全部存在且顺序无关，但如果有 NULL 值或空字符串混在其中，某些 MySQL 严格模式下会因类型不匹配报错；另外，如果表有唯一索引，insertAll() 遇到冲突会整个中止，不会跳过失败项。
- 安全写法：
User::insertAll($list, false, true)—— 第二个false表示不自动过滤非法字段，第三个true表示忽略重复键错误（需 MySQL 8.0.19+ 或开启INSERT IGNORE） - 更新前务必确认
$list中每个元素都有id（或你指定的主键字段），且类型是整型/字符串，不能是NULL - 别依赖
updateAll()自动处理时间戳，它不触发模型的createTime/updateTime自动填充逻辑
什么时候该放弃模型，直接用 Db 类
当你需要：按不同条件更新不同字段、大量数据分批次处理、更新同时要返回影响行数做校验、或涉及跨表联合更新时，模型的封装反而成了障碍。ThinkPHP 模型的抽象层在复杂写操作上弹性不足，硬套会导致代码绕弯、难调试、难复用。
比如一个导出后批量标记“已处理”的场景，原始 ID 列表可能上万，用模型循环 save() 会建上万条连接；而用 Db::execute("UPDATE user SET handled = 1 WHERE id IN ? ", [$idList]) 一条语句搞定，还支持 IN 参数自动分片（v6.1+）。
-
Db::table('user')->where('id', 'in', $ids)->update(['handled' => 1])是最简方案，但注意$ids超过 1000 项时 MySQL 可能报Packet too large - 真要处理超大集合，得手写分块：用
array_chunk($ids, 500)循环执行 - 模型的
scope、append、hidden在Db层完全失效，这点必须提前接受
实际项目里，模型适合“单条读写+业务逻辑强耦合”的场景；批量、高性能、灵活条件更新，早切到 Db 更省心。别为了“用模型”而强行封装，TP 的 Db 类本身已经足够健壮。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
