PHP 教程：Composer 最佳实践
概述
Composer 是 PHP 应用程序的依赖管理器，最初发布于大约 8 年前，2012 年 3 月。
在 php 中使用 Composer 可以提高代码的可重用性，并使你的项目能够轻松地集成来自Packagist（主要的 PHPComposer 库）的 PHP 库。今天，我们将重点介绍几个部署最佳实践。
Composer 可能会变慢
这篇文章将关注如何让 Composer 速度更快，并在每次部署应用程序时不再需要使用全新的 Composer 安装来安装软件包。
Magento 是一个需要大量内存的 composer 项目的例子。如果你需要为每个部署安装 Composer，你能想象需要多少内存吗？Composer 可能会因为内存不足而失败，如Stack Overflow 帖子所述。
尽管将包添加到你的项目中很容易，但在 Amezmo 这里，我们采用保守的方法添加新的项目依赖项，原因如下。
- 减慢初始 Composer 安装速度
- 每个 Composer 包都会增加新安全问题的可能性
最佳做法
–no-ansi
此标志禁用 ANSI 输出，这意味着彩色输出将被禁用。彩色输出，如绿色和红色字体颜色以及人眼喜欢的背景颜色。这对于我们手动运行 Composer 时非常有用，但是对于自动部署，我们不想用奇怪的字符扰乱我们的日志文件。
–no-interaction
同样，在自动化部署的环境中，我们不希望部署在等待输入时停滞不前。此标志阻止 Composer 要求用户输入。
–optimize-autoloader
此标志告诉 Composer 将生成的代码自动加载。autoloader 是当你的入口点确实需要 ‘vendor/autoload.php’ 时调用的；
–no-progress
由于进度报告使用特殊的终端 ANSI 代码，因此我们不希望报告进度，因为它会使我们的日志文件混乱。在进行非交互式
部署和 composer 安装时，这是完全没有必要的。
–no-dev
这一点至关重要。我们从不希望将开发包安装到生产服务器上。像 phpunit 和其他不应让其投入生产的软件包被视为 “dev”软件包。它们在 composer.json 文件中的 “require-dev” 属性下具有特殊条目。
–profile
这个是可选的，但是我总是喜欢包含它，因为它显示了 Composer 用于安装单个依赖项的内存量。
如何在部署时缓存 Composer 程序包
现在，我们已经定义了生产级 composer 安装命令，让我们简单地介绍一下在部署时使 Composer 更快的方法。
步骤 1。
在你的 Webroot 之外的某个地方创建一个全局 Composer vendor 目录，当然该目录不能公开访问。
注意：Amezmo 使用如下所示的根目录布局，因此我们将在下面的 bash 命令中使用它。当然，你可以用自己的目录替换
这些目录，并且可以实现所需的结果。
/webroot
|----logs
|----vendor
|----storage
|----current -> /webroot/release/${TIMESTAMP}.${COMMIT_ID}
|----release
|-------${TIMESTAMP}.${COMMIT_ID}
|-------${TIMESTAMP}.${COMMIT_ID/webroot/vendor 是我们的全局软件包目录，将从中为每个版本创建链接。
运行以下命令从 release 目录创建的 vendor 目录链接到全局 vendor 目录。每次部署时都必须执行此操作，并且在从发行目录运行 composer 安装之前。
ln -sT /webroot/vendor webroot/release/${TIMESTAMP}.${COMMIT_ID}/vendor请注意，从 release 目录运行 composer install 之前，运行上述命令至关重要。以下是步骤：
- 应该创建 release 目录
- 运行 Git 获取源代码
- 执行以上命令
- 最后运行 composer install
按照上述顺序完成所有操作后，你的软件包将被 “缓存” 到 /webroot/vendor 目录中，并且每次部署应用程序时都不需要重新安装软件包。
结论
- 定义了一个 Composer 命令，该命令消除了所有不必要的功能。
- 重点介绍了在部署时缓存 Composer 软件包的最佳实践部署模式。
第 1 步。
在 Webroot 完全不在的地方创建一个全局 Composer 供应商目录，并（此段落重复，应删除）