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

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

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

这个问题没有确切的答案。

一般来说，composer不应该做构建系统应该做的事情，你也不应该把composer放在上面。锁定VCS。作曲家可能会奇怪地把它写反了。最终用户而不是产品不应该使用锁文件。通常你的构建系统会保存快照、可重用的dirs等等，而不是每次都保存一个空的dir。从composer签出库的人可能希望该库使用锁，以便对库加载的依赖项进行测试。

另一方面，这会显著增加版本管理的负担，因为依赖关系将被严格锁定，因此几乎可以肯定每个库都需要多个版本。如果每个库可能都有一个稍微不同的版本，那么你需要一些多库版本支持，你也可以很快看到需要的依赖关系的大小，因此建议将它保留在叶子上。

Taking that on board, I really don't find lock files to be useful either libraries or your own workdirs. It's only use for me is in my build/testing platform which persists any externally acquired assets only updating them when requested, providing repeatable builds for testing, build and deploy. While that can be kept in VCS it's not always kept with the source tree, the build trees will either be elsewhere in the VCS structure or managed by another system somewhere else. If it's stored in a VCS it's debatable whether or not to keep it in the same repo as source trees because otherwise every pull can bring in a mass of build assets. I quite like having things all in a well arranged repo with the exception of production/sensitive credentials and bloat.

SVN can do it better than git as it doesn't force you to acquire the entire repo (though I suspect that's not actually strictly needed for git either but support for that is limited and it's not commonly used). Simple build repos are usually just an overlay branch you merge/export the build tree into. Some people combine exernal resources in their source tree or separate further, external, build and source trees. It usually serves two purposes, build caching and repeatable builds but sometimes keeping it separate on at least some level also permits fresh/blank builds and multiple builds easily.

对此有许多策略，但没有一种特别适合持久化源代码列表，除非您在源代码树中保留外部源代码。

文件中还有哈希值，两个人更新包时如何合并?光这一点就足以让你认为这可能是误解了。

The arguments people are putting forward for lock files are cases where they've taken a very specific and restrictive view of the problem. Want repeatable builds and consistent builds? Include the vendor folder in VCS. Then you also speed up fetching assets as well as not having to depend on potentially broken external resources during build. None of the build and deploy pipelines I create require external access unless absolutely necessary. If you do have to update an external resource it's once and only once. What composer is trying to achieve makes sense for a distributed system except as mentioned before it makes no sense because it would end up with library dependency hell for library updates with common clashes and updates being as slow as the slowest to update package.

此外，我更新猛烈。每次开发时，我都会更新和测试所有内容。有一个非常非常小的窗口，显著的版本漂移潜入。实际上，当支持语义版本时，这往往是为作曲家准备的，你不应该有那么多兼容性问题或损坏。

In composer.json you put the packages you require and their versions. You can lock the versions there. However those packages also have dependencies with dynamic versions that wont be locked by composer.json (though I don't see why your couldn't also put them there yourself if you do want them to be version locked) so someone else running composer install gets something different without the lock. You might not care a great deal about that or you might care, it depends. Should you care? Probably at least a little, enough to ensure you're aware of it in any situation and potential impact, but it might not be a problem either if you always have the time to just DRY run first and fix anything that got updated.

The hassle composer is trying to avoid sometimes just isn't there and the hassle having composer lock files can make is significant. They have absolutely no right to tell users what they should or shouldn't do regarding build versus source assets (whether to join of separate in VCS) as that's none of their business, they're not the boss of you or me. "Composer says" isn't an authority, they're not your superior officer nor do they give anyone any superiority on this subject. Only you know your real situation and what's best for that. However, they might advise a default course of action for users that don't understand how things work in which case you might want to follow that but personally I don't think that's a real substitute for knowing how things work and being able to properly workout your requirements. Ultimately, their answer to that question is a best guess. The people who make composer do not know where you should keep your composer.lock nor should they. Their only responsibility is to tell you what it is and what it does. Outside of that you need to decide what's best for you.

Keeping the lock file in is problematic for usability because composer is very secretive about whether it uses lock or JSON and doesn't always to well to use both together. If you run install it only uses the lock file it would appear so if you add something to composer.json then it wont be installed because it's not in your lock. It's not intuitive at all what operations really do and what they're doing in regards to the json/lock file and sometimes don't appear to even make sense (help says install takes a package name but on trying to use it it says no).

要更新锁或应用json中的更改，你必须使用update，你可能不想更新所有内容。锁优先选择应该安装什么。如果有一个锁文件，它就是所使用的。你可以在一定程度上限制更新，但系统仍然一团糟。

更新需要一段时间，几gb的内存。我也怀疑，如果你拿起一个项目，它已经有一段时间没有被碰过了，从它的版本来看，随着时间的推移，它可能不会有效地做到这一点，这只是扼杀它。

当涉及到秘密的复合命令时，它们非常非常狡猾，你不能期望它是复合的。默认情况下，composer remove命令似乎映射到composer update和composer remove。

你真正需要问的问题不是你是否应该把锁保存在你的源树中，或者你是否应该以某种方式将它保存在某个地方，而是你应该问它实际上是做什么的，然后你可以自己决定什么时候需要将它保存在哪里。

I will point out that having the ability to have the lock is a great convenience when you have a robust external dependency persistence strategy as it keeps track of you the information useful for tracking that (the origins) and updating it but if you don't then it's neither here not there. It's not useful when it's forced down your throat as a mandatory option to have it polluting your source trees. It's a very common thing to find in legacy codebases where people have made lots of changes to composer.json which haven't really been applied and are broken when people try to use composer. No composer.lock, no desync problem.

如果你担心你的代码被破坏，你应该提交编写器。锁定您的版本控制系统，以确保所有项目合作者使用相同版本的代码。如果没有锁定文件，您每次都会得到新的第三方代码。

例外情况是当你使用元应用程序时，需要在安装时更新依赖关系的库(如Zend Framework 2 Skeleton应用程序)。因此，目标是在每次开始开发时获取最新的依赖项。

来源:作曲者:It’s All About the Lock File

请参见:编写器更新和安装之间的区别是什么?

You then commit the composer.json to your project and everyone else on your team can run composer install to install your project dependencies. The point of the lock file is to record the exact versions that are installed so they can be re-installed. This means that if you have a version spec of 1.* and your co-worker runs composer update which installs 1.2.4, and then commits the composer.lock file, when you composer install, you will also get 1.2.4, even if 1.3.0 has been released. This ensures everybody working on the project has the same exact version. This means that if anything has been committed since the last time a composer install was done, then, without a lock file, you will get new third-party code being pulled down. Again, this is a problem if you’re concerned about your code breaking. And it’s one of the reasons why it’s important to think about Composer as being centered around the composer.lock file.

来源:作曲者:It’s All About the Lock File。

Commit your application's composer.lock (along with composer.json) into version control. This is important because the install command checks if a lock file is present, and if it is, it downloads the versions specified there (regardless of what composer.json says). This means that anyone who sets up the project will download the exact same version of the dependencies. Your CI server, production machines, other developers in your team, everything and everyone runs on the same dependencies, which mitigates the potential for bugs affecting only some parts of the deployments. Even if you develop alone, in six months when reinstalling the project you can feel confident the dependencies installed are still working even if your dependencies released many new versions since then.

来源:作曲家-基本用法。

对于应用程序/项目:当然可以。

composer文档中强调了这一点:

提交应用程序的编写器。锁定(连同composer.json)到版本控制。

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

对于图书馆:可能不会。

作曲家的文档中提到了这个问题:

注意:对于库，不一定建议提交锁文件(…)

并在这里声明:

对于你的库，你可以提交作曲家。如果你想锁定文件。这可以帮助您的团队始终针对相同的依赖版本进行测试。但是，这个锁文件不会对依赖于它的其他项目产生任何影响。它只对主要项目有影响。

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

不应该直接在生产端更新依赖项。 你应该版本控制你的作曲家。锁文件。 您不应该对实际依赖项进行版本控制。

1. 您不应该直接在Production上更新依赖项，因为您不知道这会如何影响代码的稳定性。新的依赖关系可能会引入错误，它可能会改变代码行为的方式，影响你自己的行为，它可能与其他依赖关系不兼容，等等。你应该在开发环境中完成这些工作，然后进行适当的QA和回归测试等。

2. You should version control your composer.lock file, because this stores information about your dependencies and about the dependencies of your dependencies that will allow you to replicate the current state of the code. This is important, because, all your testing and development has been done against specific code. Not caring about the actual version of the code that you have is similar to uploading code changes to your application and not testing them. If you are upgrading your dependencies versions, this should be a willingly act, and you should take the necessary care to make sure everything still works. Losing one or two hours of up time reverting to a previous release version might cost you a lot of money.

你会看到一个关于不需要作曲家的论点。锁是你可以在你的作曲器中设置你需要的确切版本。Json文件，这样，每次有人运行composer install时，它都会为他们安装相同的代码。这是不对的，因为您的依赖项有它们自己的依赖项，并且它们的配置可能以允许更新到反版本，甚至可能是整个版本的格式指定。

这意味着即使您指定在编写器中使用Laravel 4.1.31。json, Laravel在它的作曲家。2.*. json文件可能需要它自己的依赖，如Symfony event-dispatcher: 有了这种配置，你可能会得到带有Symfony事件调度程序2.4.1的Laravel 4.1.31，而你团队中的其他人可能会得到带有事件调度程序2.6.5的Laravel 4.1.31，这一切都取决于你最后一次运行composer安装是什么时候。

有了作曲家。版本系统中的Lock文件将存储此子依赖项的确切版本，因此，当您和您的队友进行composer安装时(这是您将基于composer. Lock安装依赖项的方式)，您将获得相同的版本。

如果你想更新呢?然后在您的开发环境中运行:composer update，这将生成一个新的作曲器。锁文件(如果有新东西)，在你测试它，QA测试和回归测试之后。您可以推动它，让其他人下载新的作曲器。锁，既然安全升级。

3. You shouldn't version control your actual dependencies, because it makes no sense. With the composer.lock you can install the exact version of the dependencies and you wouldn't need to commit them. Why would you add to your repo 10000 files of dependencies, when you are not supposed to be updating them. If you require to change one of this, you should fork it and make your changes there. And if you are worried about having to fetch the actual dependencies each time of a build or release, composer has different ways to alleviate this issue, cache, zip files, etc.