Laravel 服务容器的优势是什么？

[PHPNewbie]

刚入门 Laravel 服务容器。Laravel 的服务容器，对象的实例化由以下这种方式完成：

$obj1 = $container->make('class1', 'class2');
$obj2 = $container->make('class3', 'class4');

而以下这种方式的实例化同样可以做到：

$obj1 = new class1(new class2());
$obj2 = new class3(new class4());

那服务容器的优势到底是什么呢？ 希望大佬能够用具体例子来体现或是解释一下服务容器的优势，小的多谢了。

[onion83]

@abcbuzhiming fastcgi 或者说 php-fpm 本来就是用于快速处理请求而生的，常见用于 web。在这种模式下通常会有一个最长的执行时间，超时或者 core 的时候会被 master 从进程池回收掉。

fastcgi 的应用场景：对业务完整容忍度要求相对低，业务复杂且外部调用不可控（ db\network\file ），业务初期快速开发。但缺点是没有原生的连接池，无法实现资源共享，进程间只能通过 apcu 扩展进行内存共享。

swoole/workman (daemon) 的应用场景：业务稳定，需要更为底层的 handle tcp 状态 ,需要精确把握每个细节。常用于 tcp / websocket server 等开发。好处是：worker 之间通过静态类变量 /table/Atomic 甚至是 global 进行共享，程序性能实现最大化。缺点是，对开发人员要求较高，原本同步的代码会变为异步，增加复杂度，部署相对不便。

综上述：我认为因为应用场景的不同，我认为是否常驻内存不是关键。

Laravel 是一个应用层的开发框架，swoole (cli) / nginx+php-fpm / apache+mod-php 只是 php 运行的一种模式，Zend Optimizer/JIT 更是语言编译器的东西。三者根本不是一个维度的东西，没有什么好比较的，而且谁说 Laravel 不能在 swoole 在上面跑？

问题 1:
“近年来 CGI 模式以请求——脚本载入——执行完毕——卸载的方式，受到了 jit 等模式的挑战 ……”
错误，不是一个维度的东西，挑战什么？

问题 2:
“ swoole 从设计上是常驻内存的……”
应为以 daemon 的形式常驻系统，代码一次载入（编译）长期运行，能享受到 opcache/jit 的红利。

问题 3:
“这玩意在 CGI 模式下真是常驻内存的吗，我鲜有看到这方面的描述 ……”
请尝试 Google “ php-fpm share opcache ”

[leunggamciu]

使用容器来`make`一个实例和手动`new`一个实例最主要的区别是在于依赖的解决。使用`new`，你需要手动传递所有必需的依赖；而使用`make`，当依赖被提前配置好的情况下，容器会帮你解决这部分依赖。这个和接口应该没有什么关系吧

[iVanilla]

@abcbuzhiming 比性能更差？ Symfony 和 Zend Framework 表示不服

[hhxsv5]

Swoole 来拯救低性能的 Laravel，LaravelS github.com/hhxsv5/laravel-s 有兴趣可尝试下。