ThinkPHP提供了灵活的全局配置功能，采用最有效率的PHP返回数组方式定义，支持惯例配置、公共配置、模块配置、调试配置和动态配置。 对于有些简单的应用，你无需配置任何配置文件，而对于复杂的要求，你还可以增加动态配置文件。 系统的配置参数是通过静态变量全局存取的，存取方式简单高效。 # 配置格式 ## PHP数组定义 ThinkPHP框架中默认所有配置文件的定义格式均采用返回**PHP数组**的方式，格式为： ~~~ //项目配置文件 return array( 'DEFAULT_MODULE' => 'Index', //默认模块 'URL_MODEL' => '2', //URL模式 'SESSION_AUTO_START' => true, //是否开启session //更多配置参数 //... ); ~~~ 配置参数不区分大小写（因为无论大小写定义都会转换成小写），所以下面的配置等效： ~~~ //项目配置文件 return array( 'default_module' => 'Index', //默认模块 'url_model' => '2', //URL模式 'session_auto_start' => true, //是否开启session //更多配置参数 //... ); ~~~ 但是我们建议保持大写定义配置参数的规范。 还可以在配置文件中可以使用二维数组来配置更多的信息，例如： ~~~ //项目配置文件 return array( 'DEFAULT_MODULE' => 'Index', //默认模块 'URL_MODEL' => '2', //URL模式 'SESSION_AUTO_START' => true, //是否开启session 'USER_CONFIG' => array( 'USER_AUTH' => true, 'USER_TYPE' => 2, ), //更多配置参数 //... ); ~~~ > 需要注意的是，二级参数配置区分大小写，也就说读取确保和定义一致。 ## 其他配置格式支持 也可以采用`yaml/json/xml/ini`以及自定义格式的配置文件支持。 我们可以在**应用入口文件**中定义应用的配置文件的后缀，例如： ~~~ define('CONF_EXT','.ini'); ~~~ 定义后，应用的配置文件（包括模块的配置文件）后缀都统一采用.ini。 > 无论是什么格式的配置文件，最终都会解析成数组格式。 > 该配置不会影响框架内部的配置文件加载。 **ini格式**配置示例： ~~~ DEFAULT_MODULE=Index ;默认模块 URL_MODEL=2 ;URL模式 SESSION_AUTO_START=on ;是否开启session ~~~ **xml格式**配置示例： ~~~ <config> <default_module>Index</default_module> <url_model>2</url_model> <session_auto_start>1</session_auto_start> </config> ~~~ **yaml格式**配置示例： ~~~ default_module:Index #默认模块 url_model:2 #URL模式 session_auto_start:True #是否开启session ~~~ **json格式**配置示例： ~~~ { "default_module":"Index", "url_model":2, "session_auto_start":True } ~~~ 除了`yaml/json/xml/ini`格式之外，我们还可以自定义配置格式，定义如下： ~~~ define('CONF_EXT','.test'); // 配置自定义配置格式（后缀） define('CONF_PARSE','parse_test'); // 对应的解析函数 ~~~ 假设我们的自定义配置格式是类似` var1=val1&var2=val2` 之类的字符串，那么parse_test定义如下： ~~~ function parse_test($str){ parse_str($str,$config); return (array)$config; } ~~~ > CONF_PARSE定义的解析函数返回值必须是一个PHP索引数组。 # 配置加载 在ThinkPHP中，一般来说应用的配置文件是自动加载的，加载的顺序是： #### 惯例配置->应用配置->模式配置->调试配置->状态配置->模块配置->扩展配置->动态配置 > 以上是配置文件的加载顺序，因为后面的配置会覆盖之前的同名配置（在没有生效的前提下），所以配置的优先顺序从右到左。 下面说明下不同的配置文件的区别和位置： ## 惯例配置 惯例重于配置是系统遵循的一个重要思想，框架内置有一个惯例配置文件（位于`ThinkPHP/Conf/convention.php`），按照大多数的使用对常用参数进行了默认配置。所以，对于应用的配置文件，往往只需要配置和惯例配置不同的或者新增的配置参数，如果你完全采用默认配置，甚至可以不需要定义任何配置文件。 > 建议仔细阅读下系统的惯例配置文件中的相关配置参数，了解下系统默认的配置参数。 ## 应用配置 应用配置文件也就是调用所有模块之前都会首先加载的公共配置文件（默认位于`Application/Common/Conf/config.php`）。 > 如果更改了公共模块的名称的话，公共配置文件的位置也相应改变 ## 模式配置（可选） 如果使用了普通应用模式之外的应用模式的话，还可以为应用模式（后面会有描述）单独定义配置文件，文件命名规范是： `Application/Common/Conf/config_应用模式名称.php`（仅在运行该模式下面才会加载）。 > 模式配置文件是可选的 ## 调试配置（可选） 如果开启调试模式的话，则会自动加载框架的调试配置文件（位于`ThinkPHP/Conf/debug.php`）和应用调试配置文件（位于`Application/Common/Conf/debug.php`） ## 状态配置（可选） 每个应用都可以在不同的情况下设置自己的状态（或者称之为应用场景），并且加载不同的配置文件。 举个例子，你需要在公司和家里分别设置不同的数据库测试环境。那么可以这样处理，在公司环境中，我们在入口文件中定义： ~~~ define('APP_STATUS','office'); ~~~ 那么就会自动加载该状态对应的配置文件（位于`Application/Common/Conf/office.php`）。 如果我们回家后，我们修改定义为： ~~~ define('APP_STATUS','home'); ~~~ 那么就会自动加载该状态对应的配置文件（位于`Application/Common/Conf/home.php`）。 > 状态配置文件是可选的 ## 模块配置 每个模块会自动加载自己的配置文件（位于`Application/当前模块名/Conf/config.php`）。 如果使用了普通模式之外的其他应用模式，你还可以为应用模式单独定义配置文件，命名规范为： `Application/当前模块名/Conf/config_应用模式名称.php`（仅在运行该模式下面才会加载）。 模块还可以支持独立的状态配置文件，命名规范为： `Application/当前模块名/Conf/应用状态.php`。 如果你的应用的配置文件比较大，想分成几个单独的配置文件或者需要加载额外的配置文件的话，可以考虑采用扩展配置或者动态配置（参考后面的描述）。 # 读取配置 无论何种配置文件，定义了配置文件之后，都统一使用系统提供的C方法（可以借助Config单词来帮助记忆）来读取已有的配置。 用法： #### C('参数名称') 例如，读取当前的URL模式配置参数： ~~~ $model = C('URL_MODEL'); // 由于配置参数不区分大小写，因此下面的写法是等效的 // $model = C('url_model'); ~~~ 但是建议使用大写方式的规范。 > 注意：配置参数名称中不能含有 “.” 和特殊字符，允许字母、数字和下划线。 如果`url_model`尚未存在设置，则返回NULL。 支持在读取的时候设置默认值，例如： ~~~ // 如果my_config尚未设置的话，则返回default_config字符串 C('my_config',null,'default_config'); ~~~ C方法也可以用于读取二维配置： ~~~ //获取用户配置中的用户类型设置 C('USER_CONFIG.USER_TYPE'); ~~~ 因为配置参数是全局有效的，因此C方法可以在任何地方读取任何配置，即使某个设置参数已经生效过期了。 # 动态配置 之前的方式都是通过预先定义配置文件的方式，而在具体的操作方法里面，我们仍然可以对某些参数进行动态配置（或者增加新的配置），主要是指那些还没有被使用的参数。 设置格式： #### C('参数名称','新的参数值') 例如，我们需要动态改变数据缓存的有效期的话，可以使用 ~~~ // 动态改变缓存有效期 C('DATA_CACHE_TIME',60); ~~~ > 动态配置赋值仅对当前请求有效，不会对以后的请求造成影响。 动态改变配置参数的方法和读取配置的方法在使用上面非常接近，都是使用C方法，只是参数的不同。 也可以支持二维数组的读取和设置，使用点语法进行操作，如下： ~~~ // 获取已经设置的参数值 C('USER_CONFIG.USER_TYPE'); // 设置新的值 C('USER_CONFIG.USER_TYPE',1); ~~~ # 扩展配置 扩展配置可以支持自动加载额外的自定义配置文件，并且配置格式和项目配置一样。 设置扩展配置的方式如下（多个文件用逗号分隔）： ~~~ // 加载扩展配置文件 'LOAD_EXT_CONFIG' => 'user,db', ~~~ 假设扩展配置文件`user.php` 和`db.php`分别用于用户配置和数据库配置，这样做的好处是哪怕以后关闭调试模式，你修改db配置文件后依然会自动生效。 如果在应用公共设置文件中配置的话，那么会自动加载应用公共配置目录下面的配置文件`Application/Common/Conf/user.php`和`Application/Common/Conf/db.php`。 如果在模块（假设是Home模块）的配置文件中配置的话，则会自动加载模块目录下面的配置文件 `Application/Home/Conf/user.php` 和 `Application/Home/Conf/db.php`。 默认情况下，扩展配置文件中的设置参数会并入项目配置文件中。也就是默认都是一级配置参数，例如user.php中的配置参数如下： ~~~ <?php //用户配置文件 return array( 'USER_TYPE' => 2, //用户类型 'USER_AUTH_ID' => 10, //用户认证ID 'USER_AUTH_TYPE' => 2, //用户认证模式 ); ~~~ 那么，最终获取用户参数的方式是： ~~~ C('USER_AUTH_ID'); ~~~ 如果配置文件改成： ~~~ // 加载扩展配置文件 'LOAD_EXT_CONFIG' => array('USER'=>'user','DB'=>'db'), ~~~ 则最终获取用户参数的方式改成： ~~~ C('USER.USER_AUTH_ID'); ~~~ # 批量配置 C配置方法支持批量配置，例如： ~~~ $config = array('WEB_SITE_TITLE'=>'ThinkPHP','WEB_SITE_DESCRIPTION'=>'开源PHP框架'); C($config); ~~~ $config数组中的配置参数会合并到现有的全局配置中。 我们可以通过这种方式读取数据库中的配置参数，例如： ~~~ // 读取数据库中的配置（假设有一个config表用于保存配置参数） $config = M('Config')->getField('name,value'); // config是一个关联数组 键值就是配置参数 值就是配置值 // 例如： array('config1'=>'val1','config2'=>'val2',...) C($config); // 合并配置参数到全局配置 ~~~ 合并之后，我们就可以和前面读取普通配置参数一样，读取数据库中的配置参数了，当然也可以动态改变。 ~~~ // 读取合并到全局配置中的数据库中的配置参数 C('CONFIG1'); // 动态改变配置参数（当前请求有效，不会自动保存到数据库） C('CONFIG2','VALUE_NEW'); ~~~