控制台组件没有提供任何的立即可用的日志能力。正常来讲，你可以手动运行控制台命令观察输出结果，这就是为什么不提供日志的原因。然而，有些时候你就需要日志。举例来说，如果你是自动运行控制台命令，例如从工作或者开发脚本，很容易使用 Symfony 的日志能力而不是配置其它工具去收集控制台的输出并且编辑它。
不幸的是，命令行环境不知道你的虚拟主机或者域的名称。这就意味着如果你使用控制台命令生成了绝对的 URL 你将可能像 http://localhost/foo/bar 一样结束而并没有什么用。 为了解决这个问题，你需要配置“请求环境”，这是一种受欢迎的说明方式也就是你需要设置你的环境使得它知道当生成 URL 的时候该用哪一个。
控制台组件文档讲解了如何创建控制台命令。本指导文章将会讲解如何直接从 Controller 调用一个控制台命令。 你可能有执行只有在控制台命令中可用的某些功能的需要。通常情况下，你应该重构命令然后向服务中移动一些能够在 controller 中应用的逻辑。然而，当命令是第三方函数库的一部分时，你就会不想修正或者复制它们的代码。作为替代你可以直接执行命令。
组件文档的使用控制台命令，快捷键和内建命令页全局的看控制台选项。当你使用控制台作为全栈框架的一部分时，一些附加的全局选项也是可用的。 默认情况下，控制台命令在 dev 环境中运行，你可能要对某些命令改变这种情况。举例来说，你可能由于性能的原因想要在 prod 环境下运行一些命令。除此之外，一些命令的结果可能会由于环境的不同而不同。
组件一节（The Console Component）的控制台页介绍了如何创建控制台命令。这个指导文章介绍了在 Symfony 框架下创建控制台命令的不同之处。 自动注册命令为了使得控制台命令在 Symfony 下自动可用，在你的 bundle 中创建一个 Command 目录并且以 Command.php 为后缀创建你想要的命令。举例来说，如果你想要扩展 AppBundle 来在命令行运行，那么创建 GreetCommand.
Symfony 的标准版本默认定义了三种运行环境名为 dev, prod 和 test。环境简单的代表了用不同的配置执行相同的基础代码的方式。 为了选择每个环境需要加载的配置文件，Symfony 执行 AppKernel 类的 registerContainerConfiguration() 方法： // app/AppKernel.phpuse Symfony\Component\HttpKernel\Kernel;use Symfony\Component\Config\Loader\LoaderInterface;
最好的开发你的 Symfony 应用程序的方法就是使用 PHP 的内部网页服务器。然而，当使用老版本的 PHP 时或者当在开发环境运行应用程序时，你就会需要一个全功能的网页服务器。这篇文章介绍了在 Symfony 中使用 Apache 或者 Nginx 的一些方法。 当使用 Apache 时。你可以将 PHP 设置成 Apache module 或者使用 PHP FPM FastCGI。FastCGI 也是用 Nginx 使用 PHP 的最好的方法。
使用 Apache Router 不再是一个明智之举。应用程序的路由选择的小小的增加不至于大费周章地升级路由配置。 Apache Router 将会在 Symfony 3 中移除，我们强烈建议不要在你的应用程序中应用它。 Symfony 也快速的提供了各种各样的方法来通过一些微小的调整增加速度。其中的一种方法就是让 Apache 直接处理路由，而不是由 Symfony 直接处理。
在 Symfony 2.6 中有一个后向兼容：数据库模式稍作改变。更多细节请见 Symfony 2.6 的改变。 默认的 Symfony 的 session 存储将 session 信息写进文件。大多数的中到大型的网页使用一个数据库储存 session 的值而不是文件，因为数据库很好用并且适应多线程网页服务器环境。 Symfony 有一个内建的数据库 session 的存储解决方案名为 PdoSessionHandler。
在如何掌握并创建新的环境一章中，你学会了如何管理你的应用程序的配置。有些时候，在你的工程代码之外储存证书会对你的应用程序有好处。数据库配置就是这样一个例子。Symfony 的服务容器的灵活性使得你很容易这么做。 环境变量Symfony 将会抓取以 SYMFONY__ 作为前缀的变量并且将其设置成为服务容器中的参数。结果的参数名称都应用了一些转换： SYMFONY__ 前缀被移除；
在如何掌握并创建新的环境这一节中我们解释了 Symfony 如何在不同的配置之下使用环境来运行的应用程序的基本思想。这一节我们将会更加深入地介绍当你的应用程序自我启动时会发生什么。
你已经在 Symfony 服务容器中看到如何使用配置参数了。举例来说，存在特殊的情形比如当你想使用 %kernel.debug% 参数使得你的 bundle 中的服务进入调试模式。对于这种情况来说为了使系统理解参数的值你需要做很多工作。默认情况下你的 %kernel.debug% 参数将会被认为是简单的字符串。看看下面这个例子： // inside Configuration class$rootNode ->
Symfony 自动与默认目录结构建立联系。你可以轻松地重写这个目录来建立你自己的。默认目录结构如下： your-project/├─ app/│ ├─ cache/│ ├─ config/│ ├─ logs/│ └─ ...├─ src/│ └─ ...├─ vendor/│ └─ ...└─ web/ ├─ app.php └─ ...
每一个应用程序都是代码和一系列规定了代码如何执行相应功能的设置的集合。设置可能定义了使用的数据库或者有些东西是否应该被缓存又或者冗长的日志应该如何处理。在 Symfony 中，“环境”的思想就是可以使用很多不同的设置运行相同的代码库。举例来说，dev 环境应当使用从而使得开发简单并且有好的设置，然而 prod 环境就应当使用优化速度的设置。
Composer 是一个现代的应用程序所使用的封包管理器。使用 Composer 来管理你的 Symfony 应用程序的相关性并且在你的 PHP 工程中安装 Components。 推荐在你的操作系统中像下面介绍的那样全局安装 Composer。 在 Linux 和 Mac OS X 上安装 Composer在 Linux 和 Mac OS X 上安装 Composer，执行下列两条命令： $ curl -sS https://getcomposer.
CSRF 令牌意味着每一个用户都是不同的。这就是为什么如果你尝试缓存带有表单的页面时需要注意这点。 获取更多有关于 Symfony 中 CSRF 保护如何运作的信息，请查阅 CSRF 保护。 为什么缓存带有 CSRF 令牌的页面会出现问题典型地，每个用户都被分配了一个特定的 CSRF 令牌，这个令牌储存在校验的会话中。
由于 Symfony 的缓存使用的是标准的 HTTP 缓存头文件，Symfony 反向代理 可以很容易地就被其它的反向代理取代。Varnish 是一个强大的，开源的，HTTP 加速器可以提供缓存内容加速并且包括支持 Edge Side Includes。 使 Symfony 信任反向代理Varnish 自动在请求中将 IP 地址作为 X-Forwarded-For 转发并且去掉 X-Forwarded-Proto 的头信息。
当创建可重复利用以及可扩展的应用程序时，开发者经常面临一个选择：创建一个简单的大的 bundle 还是创建多个小的 bundle。创建一个简单的 bundle 的缺点就是不能让用户选择移除他们不需要的功能。创建多个 bundle 的缺点就是配置会变得很繁杂无聊，很多设置都需要对不同的 bundle 重复设置。
如果你打开你的应用程序配置文件（通常是 app/config/config.yml），你将会看到一些不同设置的部分，例如 framework, twig 和 doctrine。这些配置的每一个都有特定的 bundle，允许基于你的设置定义高级的选项并且让 bundle 设置为低级的，复杂的。
在 Symfony 中，你可以通过应用很多的服务来找到你自己。这些服务可以在你的应用程序的 app/config/ 目录下注册。但是如果当你想要分离 bundle 让它们应用于其它的工程中时，你就会想要让 bundle 自己拥有服务配置。这篇文章将会教你如何实现这个目标。 建立一个 Extension 类为了加载服务配置，你必须为你的 bundle 建立一个 Dependency Injection (DI) Extension。
关注时代Java
