https://framework.zend.com/manual/2.4/en/tutorials/config.advanced.html#environment-specific-system-configuration
有两个级别的配置：全局和局部也就是系统配置和应用配置。
系统配置：系统配置用来传递给Application实例。Application实例使用这些内容来定位ModuleManager和ServiceManager。
应用配置： ModuleManager在加载模块的时候会用ConfigListener合并各个模块的配置。这些配置被称为应用配置。各个模块的配置最终会和config/autoload/下的配置文件合并。
应用配置在传递给ServiceManager之前会先传给EVENT_MERGE_CONFIG事件，这将允许以后进行额外的修改
System Configuration:
在加载模块之前，我们必须得告诉Application的实例：有哪些模块、这些模块在什么地方。
系统配置里面包含的字段：
//包含整个应用中用到的模块，一般是模块的命名空间。
‘modules‘ => [
‘Application‘,
],
//module_listener_options留给ModuleManager的监听器使用（Zend\ModuleManager\Listener\ConfigListener
‘module_listener_options‘ => [
//指明了模块的存储位置，一般在/module和/vendor两个目录下。
‘module_paths‘ => [
‘./module‘,
‘./vendor‘,
//也可以使用string key
‘module_namespace‘ => ‘path_to_the_module‘s_Module_Class‘
],
//模块加载之后的全局配置文件的路径。可以使用GLOB_BRACE标记：http://cn2.php.net/glob
‘config_glob_paths‘ => [
‘config/autoload/{{,*.}global,{,*.local}.php‘,
],
//是否使用configuration cache。如果使用配置将会被缓存用于后续请求
// ‘config_cache_enabled‘ => $booleanValue,
//创建配置缓存文件的名字
// ‘config_cache_key‘ => $stringKey,
//是否使用模块类映射缓存。
// ‘module_map_cache_enabled‘ => $booleanValue,
//缓存文件名
// ‘module_map_cache_key‘ => $stringKey,
//缓存文件的路径
//‘cache_dir‘ => $stringPath,
//是否检查模块之间的依赖，默认检查。如果某个模块的抵赖模块没有加载，那这个模块也不会使用
//‘check_dependencies‘ => true,
], //以上为‘module_listener_options内容。
//用来创建自己的service manager
//‘service_listener_options‘ => [
// [
// ‘service_manager‘ => $stringServiceManagerName,
// ‘config_key‘ => $stringConfigKey,
// ‘interface‘ => $stringOptionalInterface,
// ‘method‘ => $stringRequiredMethodName,
// ],
],
//用来初始化ServiceManager的初始配置。
//必须和Zend\ServiceManager\Config兼容
//‘service_manager‘ => [],
加注释的部分都是可选的。系统配置是应用启动之前加载的，所以一般都很小。除了service_manager可以在模块配置文件中重载，其余的都是不可重写的。
根据应用场景选择配置文件：
有时候我们想在开发模式下使用一个配置，正式环境下使用另一个配置。我们可以在apache.conf或者.htaccess里面添加如下指令：
SetEnv "APP_ENV" "development"
在PHP中使用getenv()或者$_SERVER[]来获取服务器环境变量，然后根据环境变量设置配置。
‘config_glob_paths‘ => [
sprintf(‘config/autoload/{,*.}{global,%s,local}.php‘, $env)
]
模块配置：
每一个模块都可以提供自己的配置文件。
使用getConfig()返回模块自己的配置，，这个方法会被moduleManager加载模块的时候自动调用。
//File：module.php
public function getConfig()
{
return include __DIR__ . ‘/config/module.php‘;
}
getConfig为所有ServiceManager提供的可获得的Manager类（如：ContorllerManager。。）提供配置。
如果想针对某一个manager类可以使用相应的模块方法，如：getControllerConfig()等等。https://framework.zend.com/manual/2.4/en/tutorials/config.advanced.html#configuration-mapping-table
配置信息的优先级：
各种配置的合并顺序：
1、 module类里的各种服务配置方法
2、getConfig()返回的配置，会覆盖其他的服务配置方法。注意：该方法返回的配置不会被缓存（所以最好使用各个不同的服务配置方法）。
操作合并的配置信息：
合并所有的配置但未传递给ServiceManager之前，Zend\ModuleManager\Listener\ConfigListener会触发Zend\ModuleManager\ModuleEvent::EVENT_MERGE_CONFIG事件。通过监听这个事件你可以对已经合并的配置进行操作。
<?php
namespace FOO;
use Zend\ModuleManager\ModuleEvent;
use Zend\ModuleManager\ModuleManager;
class Module
{
public function init(ModuleManager $moduleManager)
{
$events = $moduleManager->getEventManager();
$events->attach(ModuleEvent::EVENT_MERGE_CONFIG, array($this, ‘onMergeConfig‘));
}
public function onMergeConfig(ModuleEvent $e)
{
$configListener = $e->getConfigListener();
$config = $configListener->getMergedConfig(false);
if (isset($config[‘some_key‘])) {
unset($config[‘some_key‘]);
}
$configListener->setMergedConfig($config);
}
}
配置信息合并的工作流程：
系统配置：
定义在config/application.config.php；
不会合并；
允许程序化的操控配置。
配置信息传递给Application的实例。ModuleManager按顺序初始化系统。
Application配置：
ModuleManager按以下顺序合并每一个定义在系统配置里的module类：
Module类方法里面定义的服务配置
Module::getConfig()返回的配置
service configuration里的config_glob_paths定义的文件设置
ConfigListener 触发的EVENT_MERGE_CONFIG事件：ConfigListener何必配置，其他监听器操控配置（修改）
最终合并好的配置传递给ServiceManager。