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