我倾向于使用Yii应用程序参数，主要原因是这类参数的值会根据代码运行的环境而改变。所以我将有一个运行的构建系统（我使用Phing），并从一个非版本控制的文件（如build.properties）中提取设置。
因此，任何开发数据库设置，开发域设置，API沙盒地址等都将加载到我的开发环境中，并且当在实时服务器上运行构建时，将使用正确的生产值。
如果你在某种php文件中设置了这些值，那么版本控制的跟踪就会出现问题，因为每次你在开发环境中构建时，都会对你的index.php文件进行修改，有些人甚至会错误地提交这些修改。
所以总而言之，我想说如果它们是真正的常量--在任何代码运行的环境中都是一样的--那么它们可能是一个常量。如果这些值可能会改变，取决于代码运行的地方，那么我的首选是将它们放在参数中，让您的构建系统从一个非版本控制的文件加载它们。

常量的主要缺点（同时也是优点）是它们是常量。一旦你设置了它，你就不能改变它。这是这里唯一重要的事情。你应该对那些在执行过程中永远不会改变的值使用常量，而对其他所有东西使用参数。
当你开始为你的应用编写测试时，常量可能是一个真正的PITA。它会告诉你，许多你认为是常量的东西实际上并不是常量。在这一点上，参数更灵活--你可以很容易地更改它们，或者通过合并配置数组在配置级别进行调整。使用常量可能会使您陷入不可配置应用程序的陷阱，这些应用程序在不修改硬编码常量的情况下无法安装在不同的环境中。
此外，与常量相比，访问是多一点的代码（Yii::$app->params['something']）。
这是完全不相关的。作为一个程序员，你花在实际编写代码上的时间不到5%。额外的10次击键不会有任何区别。你应该总是从可读性的Angular 来考虑它。你写一次代码，读几百遍，所以你需要多少时间来阅读和理解代码比你花在写代码上的时间要重要得多。（Yii::$app->params就是其中之一）使您的代码更容易理解，特别是对于其他程序员。
但是如果您真的想编写更少的代码，您总是可以创建一个 Package 器函数来实现对参数的快速访问。

function p($name) {
    return Yii::$app->params[$name];
}

echo p('my-param');