针对一个完整的程序（框架）来说，配置是不可以避免的。配置架构好了，后面很多开发工作都可以遵循某一些指定的规则进行，这样会省很多苦力活，程序的精简在维护上面也更加方便。
一般说来一个程序必须具备三套以上的配置变量才可以算得上比较灵活
主要有：
[------ 用户顶层配置 ------]
[------ 程序默认配置 ------]
[------ 底层默认配置 ------]
这样三层结构才能在常见的程序架构中实现灵活的配置系统。
底层默认配置主要负责的是底层框架的配置。这个配置一般与实际程序所在的环境，或者跟大多接入这个框架的程序的环境都无关，也就是说，这个配置必须把握到最高程度的灵活性。打个比方，这个就好像是HK的《基本法》一样，定义的是整个HK的相关的法律配置，具体的HK公民是一般不会与基本法打交道的，只有在议会这个层面上才会调用到《基本法》里面的配置，或者更改里面的配置
对于程序默认配置主要的实施的目的就是最大程度对一个具体的（或者一类）应用系统所调用的变量进行定义。再延伸到一个普通的系统程序，可以最大程度上面无需更改太多配置就可以满足实际的运行要求。这个配置还需要注意的就是后期的扩展接口之类的了。如果一个程序不需要考虑到后期的扩展，则这个配置可以写的固定一些。针对一般的WEB应用程序来说，接口还是要的 :D，因此说这个配置最好还是考虑到后期的兼容性等。
最后一个就是与用户（最小模块程序）打交道的用户层配置环境了，实施这部分环境配置一般会采用覆盖程序默认配置来进行的。这个用于满足程序在变化的环境变量的调用。这部分完全不需要考虑到后期的接口扩展的事情。
上面说到的三个配置可以举一个简单的例子来说明：
css 框架
针对于一套css框架的底层，我们可以写的东西有：
注意，除非是非常常用的命名规则或者非常固定的样式，才会在这里使用class方式进行命名的，其他的只使用tagname方式进行定义。如 reset 里面的 body,hx, ul,ol等，向clear这种class名称放这里还可以接受
- reset 层叠样式重置文件
- global 包含类似行高、布局框架、常见样式常见定义等
针对某一个具体的系统来说，拥有上面的配置当然还不够，这个时候我们需要下面的css配置进行补充：
这个配置里面一般还是采用class方式进行定义，在命名上可以做一些简要的暗示为默认的配置。例如table 的样式名称定义为tbl，form的样式名称定义为frm等。
- element 常见元素的样式，例如当前系统表单、表格、分页等“元素”的样式定义
- layout 当前系统采用的布局的样式
再深入到某一个具体的页面，例如首页，我们则可以针对这个首页定制一个 index.css来满足首页的额外配置，这个css就不需要考虑到扩展性了，因此里面一般可以使用ID进行样式定义。
也不仅仅CSS系统才可以使用这一套思想，其他类似于javascript、php、java、html也可以使用这一套思想进行相对应的架构。
再举一个本人之前实现的javascript editor的配置架构：
—-> 底层：fckeditor.js，这一套必须是使用最灵活的配置，那当然是官方的配置了。 因此这一部分直接采用官方的配置保持不变，日后fck版本更新也不需要对这一部分进行维护，直接更新fck和后面的接口即可
—->中间层：loader.js，这个文件实现fck同步加载，默认配置环境的导入功能，同时也实现一般程序里面使用fck的默认配置（特别是早期的fck的安全问题，在这一层进行完全的关闭等控制）。同时这一层还会分离出一个默认的配置文件default_config.js便于日后的维护
—->顶层：使用 javascript:src方式直接导入loader.js，如果没有特别的配置说明，则采用默认的配置即可实现fck功能。
如果还需要具体的配置，使用js文件（HTML页面嵌入也可以）实现对上面default_config.js里面的配置项进行覆盖处理。
使用到现在，这个还可以正常使用，在fck官方版本更新的时候，除了更改loader.js里面的一些接口方法，其他的都没有改动过。
其他的领域就不一一举例了。在PHP方面的配置，本人也采用了这一套的规则，需要范例的话可以直接联系我
做系统的配置架构时候，特别需要把握我觉得有两个：一个是命名空间问题，任何语言都存在这个问题。 另外一个就是配置控制粒度的问题了。如果是底层的配置，如果这个能够实现全覆盖当然是最好的。 :D