Laravel批量更新需按场景选择方案：统一值用whereIn+update；不同值优先upsert（需唯一索引）；数值增减用increment/decrement；复杂场景用原生SQL。
Laravel 没有内置的「按每条记录不同值」批量更新方法，直接循环 save() 或 update() 会生成 N 条 SQL，性能崩盘；真正高效的方案取决于你的数据结构和场景——不是选“哪个方法最酷”，而是看“哪条路不踩坑”。
统一字段值更新：用 whereIn() + update() 最稳
这是最常见、最安全、也最容易被忽略适用边界的场景：所有目标记录要更新成**相同的值**。
- 比如把订单状态批量设为
2、把一批用户的is_active全改为1 - 底层走的是单条
UPDATE ... WHERE id IN (?, ?, ?)，数据库原生支持，无兼容性问题 - 注意
whereIn()参数必须是纯数值数组，不能是字符串（如"1,2,3"），否则报错Incorrect integer value - 若 ID 数量超千条，MySQL 默认
max_allowed_packet可能触发PDOException: SQLSTATE[HY000]: General error: 1390，需分批或改用原生 SQL
示例：
$orderIds = [1, 5, 8, 12];<br>DB::table('orders')->whereIn('id', $orderIds)->update(['status' => 2]);
每条记录不同值更新：优先用 upsert()（Laravel 9+）
当你有一组带主键/唯一键的数据，想「存在就更新，不存在就插入」，且每条更新字段值不同（如批量修正商品价格、库存），upsert() 是目前最接近“优雅”的原生方案。
- 必须有唯一索引支撑（如
id、sku、email），否则无法判断“哪条算冲突” - 第二个参数是匹配字段数组（
['id']），第三个是允许更新字段（['price', 'stock']），别把id再塞进第三个参数里 - SQLite 用户注意：仅支持 3.24+，旧版直接抛
BadMethodCallException - 不触发模型事件（
updating、updated）、不走访问器/修改器，纯 SQL 层操作
示例：
$data = [<br> ['id' => 1, 'name' => 'iPhone', 'price' => 6999],<br> ['id' => 2, 'name' => 'iPad', 'price' => 3299],<br>];<br>Product::upsert($data, ['id'], ['name', 'price']);
数值字段递增/递减：用 increment() 或 decrement()
当你要对多个记录的数值字段做「在原值基础上加减」（如库存入库、点赞数+1、阅读量+1），千万别先查再改——竞态条件和 N+1 查询一起炸。
-
increment('quantity', 5)底层生成UPDATE SET quantity = quantity + 5，原子性由数据库保证 - 它只支持单字段、单值增量；如果要同时更新
quantity和updated_at，得用DB::raw()拼写：['quantity' => DB::raw('quantity + 5'), 'updated_at' => now()] - 大批量（>500 条）仍建议避免循环调用，可结合
DB::table()->whereIn()->update()配合DB::raw()写条件表达式
示例：
foreach ([1 => 5, 2 => 3, 3 => 8] as $id => $add) {<br> Product::findOrFail($id)->increment('stock', $add);<br>}
复杂逻辑或超大数据量：绕过 Eloquent，手写原生 SQL
当你要更新上万条记录、字段逻辑嵌套（如根据其他表子查询计算新值）、或需要极致性能时，Eloquent 的开销（模型实例化、事件、类型转换）就成了瓶颈。
- 直接用
DB::statement()或DB::update()执行拼好的 SQL，绑定参数防注入 - 参考 CASE WHEN 模式：用
CASE WHEN id = ? THEN ? ... END实现每行不同值更新（如知识库中updateBatch()方法） - 务必校验输入字段是否存在于表结构中，否则易触发
SQLSTATE[42S22]: Column not found - 事务中慎用：长事务 + 大量
WHERE IN可能锁表，尤其在高并发写场景
关键点不是“能不能写”，而是“要不要承担维护成本”——这种 SQL 一旦业务变更，比 Eloquent 更难调试和复用。
