如果您更新了libs，您也希望提交锁文件。它基本上说明您的项目被锁定到您正在使用的库的那些特定版本。

如果您提交了更改，并且有人拉出了您的代码并更新了依赖项，那么锁文件应该是未修改的。如果它被修改了，那就意味着你有了一个新版本的东西。

将它放在存储库中可以确保每个开发人员都使用相同的版本。

对于应用程序/项目:肯定是的。

composer文档对此进行了说明（重点说明）:

将应用程序的composer.lock（连同composer.json）提交到版本控制中。

就像@Meza说的:你应该提交锁文件，这样你和你的合作者就可以在同一个版本上工作，并且防止你说“但是它在我的电脑上工作过”。；-）

对于库:可能不是。

composer文档对此有如下说明:

注意:对于库，不一定建议提交锁文件（。。。）

并在此声明:

对于库，如果愿意，可以提交composer.lock文件。这可以帮助您的团队始终针对相同的依赖版本进行测试。但是，这个锁文件不会对依赖它的其他项目产生任何影响。它只对主体工程有影响。

对于图书馆，我同意@Josh Johnson的回答。

在为几个项目做了两个方面的工作之后，我的立场是composer.lock不应该作为项目的一部分提交。

composer.lock是不属于项目的生成元数据。依赖项的状态应该通过对它们进行版本控制（手动或作为自动构建过程的一部分），而不是由上一个开发人员任意更新它们和提交锁文件。

如果您担心依赖关系在composer更新之间发生变化，那么您对版本控制方案缺乏信心。版本（1.0，1.1，1.2等）应该是不可变的，并且在初始特性开发之外应该避免使用“dev-”和“x.*”通配符。

提交锁文件是依赖项管理系统的一个回归，因为依赖项版本现在已经回到隐式定义的状态。

另外，您的项目不应该在每个环境中都必须重新构建或重新获取它的依赖项，特别是Prod。您的可交付内容（tar，zip，phar，目录等）应该是不可变的，并且可以通过环境进行升级而不改变。