Laravel 有很多东西。但是快不是其中之一。让我们学习一些优化技巧，以加快运行速度！
不管怎样，不可否认的是，Laravel 已经振兴了 PHP 生态系统。
对 Laravel 的评价节选
但是，由于 Laravel 竭尽全力让您的事情变得简单，这意味着它在底层做了大量工作，以确保您作为开发人员能有一个舒适的编程体验。 Laravel 所有看似「神奇」的功能都有一层又一层的代码，每当运行一个功能时都需要启动这些代码层。甚至是一个简单的异常都会深究到底层 （从错误那里开始，一直到内核）：
重点是，默认情况下，这样层层嵌套的代码，使得 Laravel 速度很慢。
Laravel 有多慢？
说实话，这个问题根本无法回答，原因有几个。
首先，目前还没有公认的、客观的、合理的标准来衡量网络应用的速度。与什么相比更快或更慢？在什么条件下？
你可能根本不会注意到 Laravel 在这里 （即使你真的很努力地眯着眼睛）， 除非你把你的目光投到最尾部。是的，亲爱的朋友们，Laravel 排在最后！ 现在，理所当然的，这些「框架」中的大多数都不是很实用，甚至没有什么用处，但它确实告诉我们，与其他更流行的框架相比，Laravel 是多么的慢。
通常情况下，这种「慢」在应用中不会出现， 因为我们日常的 Web 应用很少达到很高的数据量。但是一旦达到了（比如高达 200-500 以上的并发量），服务器就会开始阻塞而死。这时候即使扔再多的硬件也解决不了问题，基础架构费用迅速攀升，你对云计算的崇高理想轰然倒塌。
不过，嘿嘿，振作起来吧！ 这篇文章并不是讲什么不能做， 而是讲什么可以做。
四种类型的优化
在我看来，优化可以在四个不同的层面上进行（当涉及到 PHP 应用时，就是）：
所有这些类型的优化都有其存在的意义（例如，PHP-fpm 的优化是非常关键和强大的）。但本文的重点是纯粹的第 2 类优化：那些与框架相关的优化。
顺便说一下，这些编号背后没有任何理由，也不是一个公认的标准。我只是编了这些。请千万不要引用我的话说：「我们的服务器需要 type-3 优化」，否则你的团队负责人会杀了你，找到我，然后把我也杀了。
现在，我们终于到了应许之地。
n+1 查询问题是使用 ORM 时常见的问题。Laravel 有其强大的 ORM，叫 Eloquent，它是如此的漂亮，如此的方便，以至于我们常常忘记了看是怎么回事。
我们可以想象有这样一个控制器：
class OrdersController extends Controller { // ... public function getAllByCustomers(Request $request,array $ids) { $customers = Customer::findMany(); $orders = collect(); new collection foreach ($customers as $customer) { $orders = $orders->merge($customer->orders); } return view('admin.reports.orders',['orders' => $orders]); } }
太好了！更重要的是，优雅，美丽。
