Composer的优点（如果已经使用PHP框架）

Dropbox的PHPSDK严厉地建议应该使用Composer来安装和加载他们的SDK。此外，AWS的PHPSDK版本2还提供Composer作为安装/加载程序（幸运的是没有偏见）

我正在使用Codeigniter（CI）框架，它有几个简单的机制来加载模块。它有1）一个内置的“供应商”文件夹（CI称为“第三方”，Composer称为“供应商”）。2） “helper”和“library”文件夹用于我创建的控制模块，例如，

$this->load->library（“诸如此类”）3）最后，没有什么能阻止我编写普通的PHP
include/require“blah/blah.PHP”语句

我不太了解其他PHP框架，但我假设它们以类似的简单方式处理依赖关系，因为这似乎是使用框架的主要目的之一

有鉴于此，除了框架所提供的功能外，它们对Composer还有什么额外的好处？或者用Composer替代与框架对话的代码部分？总的来说，我是不是对作曲家有些不了解

Composer解决的问题是：

a） 您有一个依赖于多个库的项目

b） 其中一些库依赖于其他库

c） 你申报你所依赖的东西

d） Composer会找出需要更新哪些包的哪些版本
安装，并安装它们（意味着它会将它们下载到您的
项目）

您可以安装、更新和管理项目的依赖项。另一个有用的特性是，您得到了加载所有库的
autoload.php
文件。您再也不需要包含文件（使用任何支持PSR-0名称空间的框架）

下面是一个示例，说明如何将composer与CI一起使用。我相信您可以找到许多文章，因为使用composer非常方便。
更新软件包，并根据其他软件包巧妙地进行更新，这显然是一个好处。自动加载不是唯一的，因为CI会这样做。Composer能否以比自动加载更具选择性/用户定义的方式加载依赖项？我的大多数供应商软件包都是在非常有限的上下文中使用的，因此自动加载似乎没有必要。@tim特别是如果您不需要一直使用软件包，那么自动加载非常有用！它只在需要时及时加载类。启用APC缓存后，它就消失了。当Composer在命令行上运行以收集依赖项时，会报告内存消耗。这通常只会偶尔发生一次，并且在您的开发机器上手动执行，而不是在实时生产服务器上定期执行。@tim阅读了PHP的自动加载机制，这不是作曲家的发明。当您试图使用未加载（不存在）的类时，PHP将调用已注册的自动加载程序，并为其提供缺少的类的名称。然后，自动加载程序可以做任何它想做的事情，只需包含定义类的正确文件。它只是及时包含文件，不多不少。