我看到的具有相对优点/缺点的选项是:
基于文件的机制
这些要求您的代码在特定位置查找 ini 文件。这是一个难以解决的问题,并且总是出现在大型 PHP 应用程序中。但是,您可能需要解决问题才能找到在运行时合并/重用的 PHP 代码。
常见的方法是始终使用相对目录,或者从当前目录向上搜索以查找在应用程序的基本目录中专门命名的文件。
用于配置文件的常见文件格式是 PHP 代码、ini 格式文件、JSON、XML、YAML 和序列化 PHP
PHP 代码
这为表示不同的数据结构提供了极大的灵活性,并且(假设它是通过 include 或 require 处理的)解析的代码将从操作码缓存中获得——从而提高性能。
include_path提供了一种在不依赖额外代码的情况下抽象文件潜在位置的方法。
另一方面,将配置与代码分离的主要原因之一是分离职责。它提供了将附加代码注入运行时的路径。
如果配置是从工具创建的,则可以验证工具中的数据,但没有标准函数来转义数据以嵌入到 PHP 代码中,如 HTML、URL、MySQL 语句、shell 命令...... .
序列化数据
这对于少量配置(最多约 200 项)相对有效,并且允许使用任何 PHP 数据结构。它只需要很少的代码来创建/解析数据文件(因此您可以花费精力确保仅在适当授权的情况下编写文件)。
自动处理写入文件的内容的转义。
由于您可以序列化对象,它确实创造了一个通过读取配置文件(__wakeup 魔术方法)来调用代码的机会。
结构化文件
按照 Marcel 或 JSON 或 XML 的建议将其存储为 INI 文件还提供了一个简单的 api,用于将文件映射到 PHP 数据结构(除了 XML,用于转义数据并创建文件),同时消除代码调用使用序列化 PHP 数据的漏洞。
它将具有与序列化数据相似的性能特征。
数据库存储
在您有大量配置但对当前任务所需的内容有选择性的情况下,这是最好的考虑 - 我惊讶地发现在大约 150 个数据项中,从本地 MySQL 实例检索数据比从反序列化数据文件。
OTOH 它不是存储用于连接数据库的凭据的好地方!
执行环境
您可以在PHP 运行的执行环境中设置值。
这消除了 PHP 代码在特定位置查找配置的任何要求。OTOH 它不能很好地扩展到大量数据,并且难以在运行时进行普遍更改。
在客户端
我没有提到存储配置数据的一个地方是在客户端。再次,网络开销意味着这不能很好地扩展到大量配置。并且由于最终用户可以控制数据,因此必须以可检测到任何篡改的格式(即使用加密签名)存储数据,并且不应包含任何因泄露而受到损害的信息(即可逆加密)。
相反,这对于存储最终用户拥有的敏感信息有很多好处 - 如果您没有将其存储在服务器上,则无法从那里窃取。
网络目录
存储配置信息的另一个有趣的地方是 DNS / LDAP。这将适用于少量的小信息——但你不需要坚持第一范式——考虑一下,例如SPF。
基础设施支持缓存、复制和分发。因此,它适用于非常大的基础设施。
版本控制系统
配置,比如代码应该被管理和版本控制——因此直接从你的 VC 系统获取配置是一个可行的解决方案。但这通常会带来显着的性能开销,因此缓存可能是可取的。