laravel 10与11的查询构建器高度兼容，性能差异不来自版本升级，而取决于查询方式选择、条件组织、是否滥用eloquent及索引优化。
Laravel 10 和 11 在数据库查询构建器（Query Builder）层面保持高度兼容，核心链式调用机制、参数绑定逻辑与底层 PDO 封装均未发生结构性变更。Laravel 11 并未引入颠覆性的查询引擎升级，而是延续并微调了 10.x 的设计哲学：强调安全性、可读性与渐进式优化。真正影响性能的关键，不在于 Laravel 版本号本身，而在于你选择的查询方式——是用 Eloquent 模型、查询构建器，还是原生 SQL，以及如何组织条件逻辑。
链式调用不是语法糖，是执行顺序的显式表达
链式调用本身不增减性能开销，它只是对 Query Builder 实例的连续方法调用。每次调用（如 `where()`、`orderBy()`、`select()`）都在内部累积查询组件，最终 `get()` 或 `first()` 才触发执行。 - 条件顺序不影响 SQL 执行效率，但会影响可维护性：把高频过滤字段（如 `status`、`tenant_id`）放在前面，便于后续调试和索引识别 - 避免在链中混用 `where()` 和 `orWhere()` 而不加闭包分组，否则会生成意外的 AND/OR 组合，导致全表扫描 - 示例正确写法：```php
User::where('active', 1)
->where(function ($q) {
$q->where('role', 'admin')
->orWhere('level', '>=', 5);
})->get();
```
查询构建器 vs 原生查询：安全与灵活的取舍
查询构建器默认启用参数绑定，自动转义所有变量，杜绝 SQL 注入；原生查询（`DB::select()` 或 `DB::unprepared()`）需手动处理占位符，稍有不慎即埋下风险。 - 性能差异极小：现代 MySQL/PostgreSQL 对预处理语句缓存充分，构建器生成的 SQL 与手写 SQL 在执行计划上几乎一致 - 真正拖慢的不是“是否原生”，而是：- 未加索引的 `WHERE` 字段（如 `LIKE '%keyword%'`）
- 在 `SELECT *` 中取大量无用字段，增加网络传输与内存消耗
- 频繁调用 `count()` + `get()` 做分页，应改用 `paginate()` 内置优化
模型作用域链式调用：复用性提升不等于性能提升
本地作用域（如 `scopeActive()`、`scopeRecent()`）本质是封装好的 `where()` 调用，链式组合后仍编译为单条 SQL，不会产生额外查询。 - 它的价值在于：让 `User::active()->recent()->paid()->get()` 这类调用语义清晰、测试友好、易于组合 - 注意两点避免隐性损耗：- 作用域内避免调用 `DB::table()` 或其他模型查询，防止 N+1 或事务上下文丢失
- 不要在作用域里做 `->toSql()` 或 `->explain()` 调试操作，这会中断链式流程并触发提前执行
Eloquent 与查询构建器：别为“对象”买单，除非你需要它
这是最常被忽略的性能分水岭： - `DB::table('users')->where(...)->get()` 返回 `stdClass` 数组，轻量、快，适合报表、导出、聚合统计等只读场景 - `User::where(...)->get()` 返回 Eloquent Collection + 模型实例，每个对象含属性访问器、关系加载能力、事件钩子等，内存占用高约 3–5 倍 - 当一次查 1000 条用户基础信息时，用构建器可减少 20–40ms 响应时间（实测中位值） - 若后续要调用 `$user->posts` 或 `$user->fullNameAttribute`，才值得切换到 Eloquent不复杂但容易忽略。
