ThinkPHP6.0更新数据首选update()静态方法，适合条件更新且不依赖实例；save()需先查出模型实例，用于触发事件、验证及基于原值计算；批量更新慎用saveAll()，推荐update()或原生SQL。
ThinkPHP6.0 更新数据不能只靠 save()，尤其在没查出来就改的场景下，它会直接报错或静默失败。
用 update() 静态方法做条件更新
这是最常用、最稳妥的更新方式，适合「知道条件、不关心原值」的场景，比如后台编辑表单提交后按 ID 更新。
-
update()是模型类的静态方法，不依赖已加载的实例，也不触发模型事件（如before_update），性能高、逻辑清晰 - 写法有两种：传两个参数（数据 + 条件），或链式调用
where()后跟update() - 返回值是影响行数（
int），为0表示没匹配到数据，不是错误，需主动判断 - 如果数据里带主键（如
['id'=>1, 'name'=>'新名字']），update()会自动提取主键作为条件，但建议显式写where更可控
示例：
// 推荐：显式 where + update
$result = User::where('id', $id)->update(['name' => $name, 'email' => $email]);
// 或者：数组式写法（等价）
$result = User::update(['name' => $name, 'email' => $email], ['id' => $id]);
if ($result === 0) {
// 注意：不是 false，是 0！说明没找到对应记录
throw new \think\Exception('用户不存在');
}
用 save() 做「查出来再改」的完整流程
当你需要触发模型事件、自动验证、软删除逻辑，或要基于原值做计算（比如阅读数 +1），就必须先查出模型实例再调用 save()。
立即学习“PHP免费学习笔记（深入）”；
-
save()只能作用于已存在的模型对象，否则抛出Integrity constraint violation主键冲突错误 - 修改字段后调用
save()，默认只更新有变化的字段；想强制写入所有字段（哪怕值没变），得加force() - 如果要让某个字段执行 SQL 函数（如
score = score + 1），必须用Db::raw()包裹，直接赋值字符串会被当字面量处理
示例：
$user = User::find($id);
if (!$user) {
throw new \think\Exception('用户未找到');
}
$user->name = $name;
$user->score = Db::raw('score + 1'); // 不是 'score + 1'
$user->save(); // 只更新 name 和 score 字段
// 强制更新全部字段（含未变的）
$user->force()->save();
批量更新必须用主键，且不能混用条件
saveAll() 看起来方便，但限制极多，线上慎用。
- 只支持按主键更新，传入的数据数组中每个元素必须包含主键字段（如
'id'），否则跳过该条 - 不支持任意
where条件，也不能对非主键字段做批量条件更新（比如「把所有 status=0 的用户改成 1」就得用update()） - 返回的是数据集对象，不是影响行数，调试时容易误判成功与否
- 如果某条数据主键冲突或验证失败，整个
saveAll()不会中断，但对应那条不会生效——得自己遍历检查
示例：
$list = [
['id' => 1, 'name' => '张三', 'status' => 1],
['id' => 2, 'name' => '李四', 'status' => 1],
];
$result = User::saveAll($list); // 成功返回数据集，失败条目静默忽略
// 检查是否都写入了？
foreach ($result as $item) {
if (!$item->id) {
// 这条没保存成功
}
}
别踩这些坑
实际开发中最容易翻车的地方，往往不在语法，而在语义和边界。
-
update()和save()都不校验字段是否存在，字段名写错只会默默忽略（除非开启严格模式） - 用
Db::raw()更新时，如果字段本身是 NULL，score + 1结果还是 NULL，得用IFNULL(score, 0) + 1 - 模型的
allowField()对update()无效，只作用于save()；想控制可写字段，得在update()前手动过滤数组 - 事务中混合使用
update()和save()时，事件触发时机不同，可能导致日志、缓存清理等副作用漏掉
真正复杂的更新逻辑（比如跨表、带子查询、条件分支多），建议直接用 Db::execute() 写原生 SQL，比绕模型更可控。模型不是银弹，只是工具。
