在我看来，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.

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

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

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

“dependies”组中宝石名称后面的感叹号是什么意思?

当使用“https://rubygems.org”以外的源安装宝石时，会出现感叹号。

在过去的几个月里，我一直在摆弄Gemfiles和Gemfile。在构建自动依赖更新工具1时，会锁很多锁。下面的内容远不是决定性的，但它是理解Gemfile的一个很好的起点。锁格式。您可能还想查看Bundler的锁文件解析器的源代码。

你会在Bundler 1.x生成的锁文件中发现以下标题:

GEM(可选但非常常见)

这些依赖关系来自Rubygems服务器。这可能是Rubygems的主索引，在Rubygems.org上，也可能是一个自定义索引，比如从Gemfury和其他网站获得的索引。在本节中，你将看到:

remote:一行或多行，指定Rubygems索引的位置 规格:依赖项的列表，包含它们的版本号，以及任何子依赖项的约束

GIT(可选)

这些是来自给定git远程的依赖项。对于每个git远程，你会看到不同的这些部分，在每个部分中你会看到:

Remote: git远程。例如,git@github.com: rails / rails revision:提交Gemfile引用。Lock被锁定到 tag:(可选)Gemfile中指定的标签 Specs:在此远程中找到的git依赖项，包括版本号和任何子依赖项的约束

路径(可选)

这些依赖关系来自Gemfile中提供的给定路径。对于每个路径依赖项，你会看到不同的这些部分，在每个部分中你会看到:

Remote:路径。例如,插件/ vendored-dependency Specs:在此远程中找到的git依赖项，包括版本号和任何子依赖项的约束

平台

Ruby平台Gemfile。锁定生成。如果Gemfile中的任何依赖项指定了一个平台，那么它们将只包含在Gemfile中。当锁定文件在该平台上生成时锁定(例如，通过安装)。

依赖关系

Gemfile中指定的依赖项列表，以及其中指定的版本约束。

使用Rubygems主索引以外的源指定的依赖项(例如，git依赖项、基于路径的依赖项、依赖项)有一个!这意味着它们被“固定”到该source2上(尽管有时必须在Gemfile中查看来确定)。

RUBY版本(可选)

Gemfile中指定的Ruby版本，当此Gemfile。Lock被创建。如果Ruby版本是在.ruby_version文件中指定的，那么这一节就不会出现(因为Bundler会考虑Gemfile / Gemfile。锁定不可知的安装程序的Ruby版本)。

捆绑(捆绑器>= v1.10.x)

用于创建Gemfile.lock的Bundler版本。用于提醒安装程序更新他们的Bundler版本，如果它比创建该文件的版本更旧。

插件源码(可选，非常罕见)

理论上，Gemfile可以指定Bundler插件，也可以指定gems3，这里列出了gems3。实际上，截至2017年7月，我不知道有任何可用的插件。Bundler的这部分仍在积极开发中!

https://dependabot.com https://github.com/bundler/bundler/issues/4631 http://andre.arko.net/2012/07/23/towards-a-bundler-plugin-system/

似乎没有明确的文件谈论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.