您缺少的是运行composer install，它将导入您的软件包并创建供应商文件夹，以及autoload脚本.
确保你的相对路径是正确的.例如，PHPMailer中的示例脚本位于项目根目录下的examples/中，因此从那里加载composer autoloader的正确相对路径应该是../vendor/autoload.php.
自动加载.您在C:\Windows\SysWOW64\vendor\autoload.php中找到的php可能是一个全球composer安装，您通常会在其中放置PHPC、phpunit、phpmd等内容.
composer update是not个一样的东西，很可能是not个你想要使用的东西.如果您的代码是用您当前的包版本测试的，那么运行update可能会导致中断，这可能需要进一步的工作和测试，所以不要运行update，除非您有特定的原因并且确切地理解它的含义.进一步澄清一下-您可能只应该在本地运行composer update，而不应该在您的服务器上运行composer update，因为它很可能会 destruct 生产中的应用程序.
我经常看到一些抱怨，人们无法使用composer，因为他们无法在自己的服务器上运行它(例如，因为它是共享的，而且他们没有shell访问权限).在这种情况下，您仍然使用composer:在本地运行它(一个没有此类限制的环境)，并上传它生成的本地供应商文件夹以及所有其他PHP脚本.
运行composer update also执行composer install，如果您当前没有vendor文件夹(如果您有一个项目的新签出，则正常)，那么它将创建一个，并覆盖您已有的任何composer.lock文件，更新其中标记的包版本，这是潜在的危险.
类似地，如果您当前没有composer.lock文件(例如，如果它没有提交给项目)，那么composer install也会有效地执行composer update.因此，理解两者之间的区别至关重要，因为它们肯定是可以互换的.
还可以通过命名来更新单个包，例如:
composer update ramsey/uuid
这将重新解析composer.json中指定的版本，并将其安装到供应商文件夹中，并更新composer.lock文件以匹配.如果您只需要对一个软件包进行特定的更新，那么与通用composer update相比，这导致问题的可能性要小得多.
库not包含自己的composer.lock个文件是正常的；修复版本是由应用程序决定的，而不是由它们使用的库决定的.因此，库开发人员需要与比应用程序开发人员需要的更广泛的主机环境保持兼容性.例如，库可能与Laravel 5、6、7和8兼容，但是使用它的应用程序可能出于其他原因需要Laravel 8.
Composer 2.0消除了安装和更新结果之间的任何剩余不一致；如果你在运行composer 1.你绝对应该upgrade.