Laravel中.env与database.php配置疑问：部署Elastic Beanstalk时用哪一个？

嘿，这个问题问到点子上了——不少刚把Laravel部署到Elastic Beanstalk的开发者都会被这两个配置文件的优先级搞懵。我来给你理清楚实际生效的逻辑：

1. Laravel本地开发时的配置优先级 #

首先，Laravel的配置加载逻辑是**.env文件里的变量会覆盖config/database.php中的默认值**。你打开config/database.php就能看到类似这样的代码：

'mysql' => [
    'driver' => 'mysql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'database' => env('DB_DATABASE', 'forge'),
    // ...其他配置
],

这里env()函数的第一个参数是.env里的变量名，第二个是默认值。如果.env里设置了对应的变量，就会用.env的值；如果没设置，才会用config/database.php里写的默认值。

2. Elastic Beanstalk部署后的特殊情况 #

当你把应用部署到Elastic Beanstalk时，情况会有一点变化：

• Elastic Beanstalk会通过环境属性（你在EB控制台或配置文件里设置的变量）来管理服务器的环境变量。这些变量会直接注入到服务器的运行环境中，并且优先级高于你上传的.env文件。
• 也就是说，如果你在EB的环境属性里配置了DB_HOST、DB_DATABASE等变量，Laravel会优先读取这些值，完全忽略你本地上传的.env文件里的对应配置。
• 当然，如果EB里没设置这些变量，Laravel才会 fallback 到你上传的.env文件，再往后才是config/database.php的默认值。

3. 特殊场景：硬编码的config值 #

如果你在config/database.php里没有用env()函数，而是直接写死了配置（比如'host' => '192.168.1.1'），那不管.env或者EB的环境变量怎么设置，Laravel都会用这个硬编码的值。不过这种做法非常不推荐，会让不同环境（开发、测试、生产）的配置切换变得异常麻烦。

如何验证实际生效的配置？ #

部署完成后，你可以登录到EB实例的服务器，运行以下命令来确认：

php artisan tinker

然后在tinker里输入：

env('DB_DATABASE');

返回的结果就是当前Laravel实际使用的数据库名称。

内容的提问来源于stack exchange，提问作者user779681