循环内调用 DB::table()->get() 会触发 N+1 查询，即遍历 N 条记录时发起 N 次独立数据库查询，导致查询总数达 N+1 次，显著增加数据库负载与响应延迟。
循环内调用 DB::table()->get() 会触发 N+1 查询
这是最常见也最容易被忽略的问题：在 foreach 中反复执行查询，比如遍历用户列表后为每个用户查订单。Laravel 不会自动合并这些请求，而是发起 N 次独立 SQL，数据库连接、解析、执行开销叠加，响应时间陡增。
- 典型错误写法：
foreach ($users as $user) { $orders = DB::table('orders')->where('user_id', $user->id)->get(); } - 真实影响：100 个用户 → 至少 101 次查询（1 次查用户 + 100 次查订单），而非 2 次
- 性能拐点通常出现在 20–30 条记录后，本地可能不明显，上线后 DB CPU 突然飙升
循环内使用 DB::transaction() 导致事务嵌套失败
DB::transaction() 在循环体内重复调用，不会创建嵌套事务，而是在第一次 commit 后抛出 LogicException: A transaction is already active —— Laravel 的 PDO 连接不支持真正的嵌套事务，外层事务未结束时无法开启新事务。
- 错误模式：
foreach ($items as $item) { DB::transaction(function () use ($item) { /* ... */ }); } - 正确做法：把整个循环逻辑包进单个事务，或改用
DB::beginTransaction()+ 手动commit()/rollback() - 注意：若循环中某次操作失败，需确保能捕获异常并回滚全部，否则出现部分写入
循环中拼接动态列名仍存在 SQL 注入风险
即使没用 selectRaw()，只要列名来自用户输入（如 "product_variant_{$request->input('id')}"），并在循环里拼接使用，就和单次调用一样危险。Laravel 对列名不做任何转义，PDO 也无法参数化标识符。
- 高危示例：
foreach ($variantIds as $id) { $col = "product_variant_{$id}"; DB::table('products')->select($col)->get(); } - 攻击者传入
id=1 FROM users --，最终字段名变成product_variant_1 FROM users --，可能在特定上下文（如配合ORDER BY或错误回显）被利用 - 必须在循环外完成白名单校验，例如：
if (!in_array($id, [1, 2, 3], true)) { continue; }，且不能依赖类型自动转换
循环内频繁创建 Eloquent 模型实例消耗内存
每轮循环中用 new User() 或 User::make() 创建模型，尤其配合 toArray() 或 json_encode()，会触发大量属性监听、强制转换、访问器调用，GC 压力剧增。1000 次循环可能吃掉上百 MB 内存。
- 替代方案：直接用数组构造数据，避免走模型生命周期；必要时用
User::hydrate([])批量还原 - 警惕
$model->save()放在循环里 —— 每次都触发事件、验证、观察者，比原生查询慢 3–5 倍 - 如果只是读取，优先用
DB::table()而非User::query()，跳过模型开销
关键点在于：循环本身不是问题，问题出在每次迭代是否引入不可控的 IO、状态或安全边界破坏。真正难排查的是那些“看起来只查一次”的操作，在循环放大后暴露本质缺陷。
