容器搭建的工作流

在本章的前面部分，用了一些笔墨讲解从哪里可以定位不同的文件和类。这是因为你要在程序、类库和框架中使用服务容器。探求在Symfony完整版框架中如何配置和构建服务容器，有助于帮助你理解所有这些是如何共存的，不管你是使用完整版Symfony框架，还是只把服务容器应用在另外的程序中。

完整版框架使用了HttpKenel组件，来管理程序和Bundle中“服务容器相关配置”的加载，并且也负责处理容器的编译和缓存。就算你不用HttpKernel，你也应该了解在模块化的程序中“组织和管理配置信息”的运作方式。

操作一个被缓存的容器 ¶

开始构建容器之前，kernel会检查是否有缓存版本的容器存在。HttpKenel有一个debug选项，如果设为false，那么缓存了的容器只要存在就会被使用。如果开启了debug模式，kernel要检查配置是否新鲜（Caching Based on Resources【基于资源进行缓存】章节），如果是新鲜的，缓存版本的容器将被使用；如果不新鲜，容器将从程序级别的配置信息和bundle扩展的配置信息中，被重新构建。

请参阅编译服务容器中的~出于性能考虑剥离配置信息~小节。

程序级别的配置信息 ¶

程序级配置信息的加载，来自app/config目录。当处理扩展时，会有多个文件被加载，然后合并。这过程允许不同的配置信息用于不同的环境，比如dev生产环境和prod开发环境。

这些配置文件，包含着参数和服务，这些信息被直接读入服务容器，按照本章前面通过配置文件来设置容器中所描述的实现。它们也包含了扩展中的配置信息， 前文管理扩展的配置信息有相关描述。

Bundle级别的扩展之配置信息 ¶

按照约定，每个bunlde都包括一个扩展类（译注：BunldeNameExtension.php），它位于该bundle的DependencyInjection文件夹下。当kernel启动时，扩展类会被注册到ContainerBuilder中。当服务容器被编译时，在程序级别的配置信息中，与这个bunlde的扩展相关的内容，将被传回该扩展类（译注：load方法中的$configs数组参数），扩展类同时用于加载bundle自己的配置文件，一般会在该bundle的Resource/config文件夹下。程序级别的配置通常还会被一个Configuration对象处理，它同样位地DependencyInjection目录下。

通过Compiler Passes来实现bundle间的互动 ¶

Compiler passes常用于不同bundle间的互动，因为它们不能互相影响对方扩展类中的配置。编译器传递的一个主要的用途是对于“tagged services（带有标签的服务）”的处理，Compiler passes允许任何bundle注册自己的服务（并打上标签），然后这些服务能被其他bundles挑选出来——比如Monolog loggers，Twig Extensions以及Web Profiler的Data Collectors等。实现Compiler passes的类，通常位于DependencyInjection/Compiler目录下。

编译和缓存的过程 ¶

当编译过程加载完从配置、扩展和compiler passes中取得的服务之后，服务容器将被剥离，以生成下次所需的缓存。剥离出来的缓存版本容器，被用于随之而来的请求（request）时，格外有效率。