我考虑的问题是如何编写代码，这些代码可以轻松地知道所需配置文件的位置，并且可以从环境移植到另一个环境而无需任何编辑。我们不想编辑配置文件的位置以使代码适应每个新环境，例如每次我们将代码从开发环境移动到生产环境时。该方法不应依赖于普遍可用的资源，例如访问用户定义的环境变量或访问特定目录。例如，似乎使用DOCUMENT_ROOT作为配置文件的基本位置是可行的方法，但这不是通用的。首先，在命令行环境中，DOCUMENT_ROOT没有意义。其次，程序员可能只能访问DOCUMENT_ROOT的子文件夹。另一个要求是配置文件可能依赖于运行时已知的值，例如调用应用程序的用户，如此问题How to load a config file based on user selection from "unknown" location。
问题不在于特定环境中配置文件的最佳位置，例如Location to put user configuration files in windows。程序员仍然需要找出最佳位置，以便最终用户可以轻松找到配置文件。问题是这个位置，无论它是什么，即使它依赖于运行时已知的值，也可以以可移植的方式传递给代码。
答案 0 :(得分：0)
一种方法是设计任何脚本文件，记住它将被包含在另一个文件中，依此类推，直到我们找到一个包装器脚本，该脚本只定义配置文件的目录，以利于包含的文件和其他包含的文件。知道此目录路径后，可以从其中的命名配置文件中获取其他配置值。这是有效的，因为当我们从存储库或测试环境更新代码时，包装器脚本不会更新。这种方法似乎普遍适用：不需要任何类型的特殊支持，例如访问用户定义的环境变量或服务器中的某些特定目录。只要您可以访问代码，这是一个严格的最低期望，它就可以工作。此外，脚本通常被自然地设计为包含在另一个文件中 - 因此它很自然。
这种方法只要求我们就常量名称的约定达成一致，比如CONFIG_DIRECTORY。如果每个程序员都同意在此常量指定的位置搜索配置文件，那么代码的任何用户都可以将配置文件放在任何位置，并相应地定义此常量。
在Linux中，他们有配置文件的文件夹/ etc。因此，在很大的背景下，普遍认同的标准的概念已经存在。这与此处提出的想法相同，不同之处在于它对于所有计算机都是相同的常量，并且某些人可能无法访问该级别的服务器。而且，我们失去了为不同的包装器脚本提供不同配置目录的可能性。允许通用标准是一个恒定的名称，比如说'CONFIG_DIRECTORY＆＃39;而不是固定常数＆＃39; / etc＆＃39;，似乎只是一种额外的灵活性，没有额外的不便。它确实需要我们在一些包装器脚本中定义这个常量，但如果没有定义，我们可以回退到旧方法。如果严格应用该方法，结果将是服务器文档根目录中所需的所有脚本只是定义配置目录的简单包装器。这看起来很酷。通常人们会说在文档根目录之外放置重要代码更安全。