我认为将项目迁移到作曲家时，一个很大的好处是留下一个小的项目存储库，其中所有作曲家管理的东西（TYPO3 源 + 公共扩展）都可以从 VCS 中排除。在部署时，实时系统上的“composer install”总是会导致所需的状态而没有风险。
但是官方的 TYPO3 文档说：
您不应该在您的实时网络空间上运行 composer。您应该始终在本地或专用部署机器上运行 composer，这样您就可以测试一切是否正常。运行测试后，您可以将 vendor 和 public 文件夹部署到您的 Web 服务器。
我无法理解为什么。因为这导致每个项目存储库都需要在项目 VCS 中包含整个 TYPO3 源，尽管它们可能会被排除在外。这种方法的原因是什么？“我的”方法有什么风险？
编辑：当然我要指定确切的版本号，直到作曲家包的修订级别。这样做，我的方法还会有任何风险吗？
composer 可以以多种方式使用，我也想知道为什么 TYPO3 文档在这里表现出如此强烈的观点（没有理由？）。
它指的是这个模型：
带有 composer 的本地开发系统，用于更改 composer.json/composer.lock
构建环境/CD 流水线运行composer install --no-dev，并将现成的文件系统复制到暂存/实时系统
没有作曲家的实时服务器与用户数据集成（数据库和 /fileadmin）
这是一些人（包括我）的首选，因为它有助于在可重现（构建）环境中进行测试步骤。如果构建步骤包含的不仅仅是作曲家（例如资产构建），它也可以很好地工作。
虽然仅对于作曲家来说，如果它必须实时安装（+它的依赖项）不会有很大的不同，但是您拥有的构建步骤越多，您必须实时安装的“开发”软件就越多。这可能是一些人划清界限并决定开发 -> 构建 -> 生活是一个更强大的模型的地方。
虽然构建环境很可能在实时服务器上，但我不希望它处于已发布状态（我不知道您是否提到过）。所以我会至少做一些复制（或者更确切地说是符号链接切换），以确保构建/测试期间的问题不会影响已发布的站点。
其他模型也可以。
当您使用 composer 通过 为您的 TYPO3 环境获取源代码时，您composer install并不确切知道您将获得哪个 TYPO3 扩展的版本。composer.json 文件定义了一系列允许的版本号，而不是确切的版本号。当您有本地或部署环境时，composer 安装将为您提供版本 1 中的状态扩展 1，版本 2 中的扩展 2。然后您测试所有内容。2 周后，您决定一切正常。但是，如果您在 2 周后在您的实时系统上使用 composer，则可能会发生扩展 1 现在处于版本 2 中的情况，该版本存在严重错误。然后作曲家运行会给你带来这个扩展 1 的错误版本 2。这不是你想要的。
存在一种解决方法。