实际上，我强烈建议不要在生产服务器上安装依赖项。

我的建议是在部署机器上签出代码，根据需要安装依赖项(如果代码用于生产，则不安装开发依赖项)，然后将所有文件移动到目标机器上。

Why?

on shared hosting, you might not be able to get to a command line even if you did, PHP might be restricted there in terms of commands, memory or network access repository CLI tools (Git, Svn) are likely to not be installed, which would fail if your lock file has recorded a dependency to checkout a certain commit instead of downloading that commit as ZIP (you used --prefer-source, or Composer had no other way to get that version) if your production machine is more like a small test server (think Amazon EC2 micro instance) there is probably not even enough memory installed to execute composer install while composer tries to no break things, how do you feel about ending with a partially broken production website because some random dependency could not be loaded during Composers install phase

长话短说:在您可以控制的环境中使用Composer。您的开发机器确实符合条件，因为您已经拥有了操作Composer所需的所有东西。

在不安装-dev依赖项的情况下部署它的正确方法是什么?

要使用的命令是

composer install --no-dev

这可以在任何环境中工作，无论是生产服务器本身，还是部署机器，或者应该进行最后检查以确定是否有任何开发需求被错误地用于实际软件的开发机器。

该命令不会安装或主动卸载编写器中声明的开发需求。锁文件。

如果您不介意在生产服务器上部署开发软件组件，那么运行composer install将完成相同的工作，但只会增加移动的字节量，并创建一个更大的自动加载器声明。

现在require-dev默认启用，对于本地开发，你可以在没有——dev选项的情况下安装和更新composer。

当您希望部署到生产环境时，您需要确保编写器。Lock没有任何来自require-dev的包。

你可以用

composer update --no-dev

一旦你在本地使用——no-dev进行测试，你就可以将所有东西部署到生产环境中，并基于composer.lock进行安装。你需要在这里再次使用——no-dev选项，否则编写器会说“锁文件不包含require-dev信息”。

composer install --no-dev

注意:要小心任何可能在开发和生产之间引入差异的东西!我通常尽量避免使用require-dev，因为包含开发工具的开销并不大。

Why

在我看来，现在的Composer默认使用——dev标志是有原因的(在安装和更新时)。Composer主要在需要这种行为的场景中运行:

Composer的基本工作流程如下:

A new project is started: composer.phar install --dev, json and lock files are commited to VCS. Other developers start working on the project: checkout of VCS and composer.phar install --dev. A developer adds dependancies: composer.phar require <package>, add --dev if you want the package in the require-dev section (and commit). Others go along: (checkout and) composer.phar install --dev. A developer wants newer versions of dependencies: composer.phar update --dev <package> (and commit). Others go along: (checkout and) composer.phar install --dev. Project is deployed: composer.phar install --no-dev

正如你所看到的，——dev标志的使用(远远)多于——no-dev标志，特别是当开发人员的数量增加时。

生产部署

在不安装“开发”依赖项的情况下部署它的正确方法是什么?

嗯，作曲家。Json和composer。lock文件应该提交给VCS。不要忽略作曲家。锁定，因为它包含关于应该使用的包版本的重要信息。

当执行生产部署时，你可以将——no-dev标志传递给Composer:

composer.phar install --no-dev

作曲家。锁文件可能包含有关dev-packages的信息。这无关紧要。——no-dev标志将确保没有安装这些开发包。

当我说“生产部署”时，我指的是旨在用于生产的部署。我不是在争论作曲家是否。Phar安装应该在生产服务器上进行，或者在可以检查的登台服务器上进行。这不是我回答的范围。我只是指出如何作曲。Phar安装不安装“开发”依赖项。

无关的

——optimize-autoloader标志在生产中也可能是可取的(它会生成一个类映射，这将加速应用程序中的自动加载):

composer.phar install --no-dev --optimize-autoloader

或者当自动部署完成时:

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --optimize-autoloader

如果您的代码库支持它，您可以将——optimize-autoloader替换为——classmap- authorized。更多信息请点击这里

我认为最好是自动化这个过程:

添加作曲家。锁定文件在你的git存储库，确保你使用composer。Phar install——no-dev当你发布的时候，但是在你的开发机器中，你可以不用担心使用任何composer命令，这不会进入生产，生产将基于它的依赖锁文件。

在服务器上签出此特定版本或标签，并在替换应用程序之前运行所有测试，如果测试通过，则继续部署。

如果测试依赖于开发依赖项，因为composer没有测试范围依赖项，那么一个不太优雅的解决方案可以使用开发依赖项运行测试。Phar install)，删除供应商库，运行composer。Phar install—no-dev再次，这将使用缓存的依赖，所以更快。但如果你知道其他构建工具中作用域的概念，这就是一种hack

自动化这些，忘记其他的，去喝杯啤酒吧。

PS:正如下面的@Sven评论，不签出作曲家不是一个好主意。锁定文件，因为这将使编写器安装工作作为编写器更新。

您可以使用http://deployer.org/实现自动化，这是一个简单的工具。

在生产服务器上，我将vendor重命名为vendor-<datetime>，在部署期间将有两个vendor dirs。

HTTP cookie使我的系统选择新的供应商autoload.php，在测试之后，我在它们之间进行了完全原子/即时切换，以便为所有未来的请求禁用旧的供应商目录，然后在几天后删除前一个目录。

这避免了我在apache/php中使用的文件系统缓存所引起的任何问题，并且还允许任何活动的php代码继续使用以前的供应商dir。

尽管其他答案不推荐，但我个人还是在服务器上运行composer install，因为这比从我的临时区域(笔记本电脑上的虚拟机)进行rsync快。

我使用——无需开发——无需脚本——优化自动加载器。您应该阅读每一个文档，以检查这是否适合您的环境。