你可以在捆绑商网站上找到更多关于它的信息(为了方便起见，在下面加了重点):

After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked... This is important: the Gemfile.lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.

关于感叹号，我刚刚发现它是通过:git获取的宝石，例如。

gem "foo", :git => "git@github.com:company/foo.git"

似乎没有明确的文件谈论Gemfile。锁格式。也许是因为Gemfile。Lock只被bundle内部使用。

然而，自从Gemfile。lock是Gemfile的快照，这意味着它的所有信息都应该来自Gemfile(如果Gemfile中没有指定，则来自默认值)。

对于GEM，它列出了在Gemfile中直接或间接引入的所有依赖项。GEM下的remote告诉在哪里获取宝石，这是由Gemfile中的source指定的。

如果一个宝石没有从remote获取，PATH会告诉它所在的位置。当你声明一个依赖时，PATH的信息来自于Gemfile中的PATH。

PLATFORM来自这里。

对于DEPENDENCIES，它是由bundle解析的依赖项的快照。

你可以在捆绑商网站上找到更多关于它的信息(为了方便起见，在下面加了重点):

After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked... This is important: the Gemfile.lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.

Bundler是一个Gem管理器，通过跟踪和安装所需的Gem和版本，为Ruby项目提供了一致的环境。

Gemfile和Gemfile。锁是邦德勒宝石给予的初级产品(邦德勒本身就是宝石)。

Gemfile包含您对gem(s)的项目依赖，您手动指定了版本，但这些gem(s)的输入依赖于其他gem(s)，这些gem(s)由绑定器自动解析。

Gemfile。lock包含Gemfile中所有gem(s)的完整快照以及相关的依赖项。

当您第一次调用bundle install时，它将创建这个Gemfile。Lock并在所有后续调用中使用此文件来捆绑安装，这确保您已经安装了所有依赖项，并将跳过依赖项安装。

在不同的机器上共享代码时也会发生同样的情况

共享您的Gemfile。当你在其他机器上运行bundle install时，它会引用你的Gemfile。锁定并跳过依赖项解析步骤，相反，它将安装您在原始机器上使用的所有相同的依赖gem，这将在多台机器上保持一致性

为什么我们需要在多台机器上保持一致性?

在不同的机器上运行不同的版本可能会导致故障 代码 假设你的应用使用的是1.5.3版本，并且在14个月前就可以工作了 没有任何问题，并且您尝试在不同的机器上安装 没有Gemfile。锁定后，您将获得1.5.8版本。也许它坏了 与最新版本的一些gem(s)和您的应用程序 失败。保持一致性是最重要的(最好) 实践)。

也可以在Gemfile中更新gem(s)。使用锁定 包更新。

这是基于保守更新的概念

在我看来，PATH列出了直接来自gemspec的第一代依赖项，而GEM列出了第二代依赖项(即依赖项依赖于什么)和来自Gemfile的依赖项。PATH::remote is。因为它依赖于当前目录中的本地gemspec来查找属于PATH::spec的内容，而GEM::remote是rubygems.org，因为这是它必须去查找属于GEM::spec的内容的地方。

在Rails插件中，你会看到PATH部分，但在Rails应用程序中看不到。因为应用程序没有gemspec文件，所以PATH中没有任何东西可以放。

至于DEPENDENCIES, gembundler.com声明:

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development

由rails插件new my_plugin生成的Gemfile说了类似的话:

# Bundler will treat runtime dependencies like base dependencies, and
# development dependencies will be added by default to the :development group.

这意味着两者之间的区别

s.add_development_dependency "july" # (1)

and

s.add_dependency "july" # (2)

is that (1) will only include "july" in Gemfile.lock (and therefore in the application) in a development environment. So when you run bundle install, you'll see "july" not only under PATH but also under DEPENDENCIES, but only in development. In production, it won't be there at all. However, when you use (2), you'll see "july" only in PATH, not in DEPENDENCIES, but it will show up when you bundle install from a production environment (i.e. in some other gem that includes yours as a dependency), not only development.

这些只是我的观察，我不能完全解释为什么会是这样，但我欢迎进一步的评论。