我正在利用主机共享目录的 VM 中运行开发环境。出于多种原因，我已经将我的几个软件包移到了项目供应商目录之外，并将它们放在操作系统的根目录中。这样，当我有多个项目使用相同的依赖项运行时，我可以更新依赖项中的源代码，而不必每次都提交和运行作曲家更新。
在我的composer.json中，我的一个项目有以下内容......
"autoload": {
"psr-0": {
"Product''Common''": "/srv/deps/php-common/src/"
}
}
如您所见，我正在尝试从/srv/deps/php-common/src/加载项目的源代码。可以从 apache 正常访问此目录，我尝试手动包含其中的文件（也可以正常工作）。但是，作曲家拒绝在那里上任何课。
尝试实例化Product'Common'Sample将导致 PHP 抱怨该类不存在。
我在这里做错了什么吗？
我在这里做错了什么吗？
你可能自己猜到了，答案是"是的"。
Composer 的主要功能是在您需要的版本中添加库，包括下载，在您不需要注意的位置（除了必须将这些文件复制到生产机器
）。如果您维护库的中心位置，您如何确定它们处于您的应用程序所需的正确版本中？
此外，如果您添加具有绝对路径的自动加载，该应用程序现在取决于该确切的目录结构，该结构必须复制到应该安装的任何地方。虽然我确实知道，对于开发时间来说，只需要关心一个中心副本看起来要方便得多，但对于生产或让新开发人员准备处理该项目来说，它并不是很方便。
您是否考虑过通过使用 Phing 或 Ant 脚本来增加开发的便利性？我爱他们。我使用 Git 签出一个分支，然后在主目录中运行phing test以启动测试套件。第一步是运行 composer install ，这将获取正确的版本。
或者，我可以运行phing composer只安装，但通常我对运行测试感兴趣。我切换到一个分支，更改一些代码并运行测试。我不能忘记安装正确的库版本，它是自动完成的。
或者我想更新到最新版本。这是一个手动步骤，之后也需要运行测试，但是成功后，composer.json和composer.lock中的新依赖项将提交，并将复制到其他任何地方。
真正有助于这一点的一件事是在Github或Bitbucket上托管库，能够下载ZIP文件而不是克隆存储库 - 或者运行Satis的本地实例来生成这些ZIP文件。它使安装版本非常快。
但是要回答有关自动加载的问题：请查看vendor/composer中生成的文件。它们看起来应该工作吗？机器是否看到路径，其中的文件？