我已经看到了不同的做法,这里是一个简短的示例列表(我在这些示例中存储数据库信息)：

常数：全局,只读

define('DB_USER','user12');
define('DB_PASS','21user');

使用GLOBALS数组：全局,可变,重复,与其他全局变量混合

$GLOBALS['DB_USER']='user12';
$GLOBALS['DB_PASS']='21user';

使用非全局数组但提升了globaly：可能比第二个选项更差

$config=array(); ...

$config['DB_USER']='user12';
$config['DB_PASS']='21user';

... global $config;
    MysqL_connect('localhost',$config['DB_USER'],$config['DB_PASS']);

定义类属性:(全局,可枚举)

class Config {
    public $DB_USER='user12';
    public $DB_PASS='21user';
}

标准/选项/特点：

>编码的简易性：您不希望检查设置是否存在,或者初始化它
>易于修改：非程序员/外行可以轻松修改设置
>存放在干净的地方：不与其他变量混合(可以存储在子数组中)
>运行时修改：在某些情况下,其他开发人员可以轻松修改现有设置

在系统运行期间可能需要更改配置,因此选项1已不可行.第三种选择也不太干净.

在写这篇文章的时候,我对主观和封闭的讨论发出了重大警告.因此,请继续关注主题,并给出有效的理由来解答您的问题.

这是一个非常明显的问题,考虑到我对不同的答案非常熟悉,你可能会问,为什么我要大惊小怪呢？问题是,我正在开发一个框架,并且与另一个框架(* ahem * joomla * ahem *)不同,我不想通过他们错误的投入错误信息的解决方案,最终必须更改/在将来重新定位.

编辑：首先,配置文件的位置与我无关.如果他们愿意,我会确保人们可以轻松更改位置,但这不是必需的.
首先,廉价的虚拟主机不允许这样做,其次,就安全性而言,这真的不是一个好的选择.为什么？因为,框架需要知道配置的位置.实际上,通过默默无闻的安全措施不起作用.我宁愿修复所有RFI和XSS(例如),而不是偏执地将配置文件隐藏在多个层下.