saveAll报错90%可三步定位：检查返回值是否为false、确认$this->isUpdate是否被污染、验证主键字段是否显式存在；其本质是循环调用单条save()，失败即静默返回false，需立即用getError()获取错误信息。
saveAll 报错不是数据问题就是模型状态残留，90% 的 case 能靠三步定位：检查返回值是否为 false、确认 $this->isUpdate 是否被污染、验证主键字段是否在每条数据中显式存在。
saveAll 返回 false 却没报错信息？先看它到底干了啥
ThinkPHP 的 saveAll 不是“批量执行 SQL”，而是循环调用单条 save()，每条都走完整生命周期：验证 → 自动完成 → 事件 → 写库。只要其中一条失败（比如某个 status 值不满足 $_validate 规则），整个过程就中断并静默返回 false，不会告诉你哪条、为什么错。
- 必须在调用后立刻判断：
if ($result === false) { dump($model->getError()); }，getError()才可能拿到最后一条失败的验证提示 - 如果
getError()也为空，说明失败发生在非验证环节——常见于字段类型不匹配（如把字符串传给 int 字段）、主键缺失、或软删除字段delete_time没传导致误判为新增 - 开启 SQL 日志（
'show_sql' => true）看实际执行了哪些语句，常能发现某条UPDATE因 WHERE 条件为空而变成全表更新，被数据库拒绝
$this->isUpdate 被上一次操作污染了怎么办
这是 ThinkPHP 5/6 中最隐蔽的坑：save() 更新成功后会把模型实例的 isUpdate 属性设为 true，但之后没重置。如果你紧接着调 saveAll()，框架会误以为你是在“对同一个模型实例做批量更新”，结果要求所有数据必须带主键、且强制走 update 流程，稍有不慎就报“缺少更新条件”。
- 安全做法：在
saveAll()前手动重置 ——$model->isUpdate(false); - 更彻底的做法：不用模型实例调用，改用
Db::name('table')->saveAll($data)，完全绕过模型状态 - 如果必须用模型，确保每次
saveAll()都新建模型对象：(new User())->saveAll($data)，避免状态复用
主键字段名不对 or 数据里漏了主键？直接卡死
saveAll 默认按 id 匹配记录。如果表主键是 user_id，但数据里写的是 'uid' => 123，或者压根没传主键字段，框架既不会报错也不会更新，而是尝试插入——然后大概率撞上主键冲突或唯一索引错误。
立即学习“PHP免费学习笔记（深入）”；
- 检查数据数组每一项是否含主键字段，且键名与模型定义一致：
protected $pk = 'user_id'; - 不要依赖自动映射，显式写出主键：
['user_id' => 1, 'name' => 'a']，别写成['id' => 1, 'name' => 'a'] - 达梦等兼容性弱的数据库，
saveAll插入后无法正确读取lastInsertId()，会导致后续逻辑错乱；此时必须手动从序列取 ID 再填入数据
什么时候该放弃 saveAll，直接写原生 SQL
当批量更新字段少、逻辑简单、且对性能或原子性有要求时，CASE WHEN 原生 SQL 比 saveAll 更稳更快。它不走模型层，不触发验证和事件，也不会因为某条数据异常而中断整个批次。
- 示例（更新 status 和 sort）：
Db::execute("UPDATE think_user SET status = CASE id WHEN ? THEN ? WHEN ? THEN ? END, sort = CASE id WHEN ? THEN ? WHEN ? THEN ? END WHERE id IN (?, ?)", [1, 1, 2, 0, 1, 10, 2, 20, 1, 2]); - ID 列表必须加索引，否则
WHERE id IN (...)在大数据量下会全表扫描 - 所有
CASE分支返回值类型必须一致（如全是整型），否则 MySQL 可能隐式转成字符串，导致索引失效或比较异常
真正麻烦的从来不是语法，而是模型状态像幽灵一样漂浮在内存里——isUpdate、origin、data 三者不同步，saveAll 就成了定时炸弹。动手前先 dump($model) 看一眼这几个属性的值，比猜半天强。
