laravel 为什么要大量使用env而不是普遍用的常量定义的方式呢？
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
9
1030
收藏
我觉得：
语义化吧，本来就是和环境变量相关的东西，就类似restful一样
所以体现了它的优雅
1、常量是一次性的，值定义了就不能够修改，而env只是定义了一个环境变量，不一定就不重新赋值，两者的诉求不一样。用它自定义的封装可以少很多限制
2、便于管理，因为它是存到$_SERVER里的，排查问题的时候可以直接罗列出来
3、逼格高
因为可以根据你的实际环境快速切换项目配置
开发->测试->生产
不然就要去动配置文件，很麻烦，容易出错
参见The Twelve-Factor App。
其实通过环境变量来保存配置不是Laravel特有的实践。
@machenchi0207 是正解。
项目一般耦合性越低，越利于扩展。当处于不同的环境如开发、测试、生产时，只要各自维护自己的env文件即可。如果都写在代码里，从开发推倒测试环境时，首先就是一个个去把代码里的配置信息改掉，运维测试人员会疯掉的:)
个人感觉应该是env可以很好地区分正式环境和开发环境，如果定义成常量的话。提交到正式环境还要修改。也可能会导致正式环境有问题。
最近也在看 Laravel，刚接触的时候也同样有这个疑问。Laravel 是用的 DotEnv 这个库，README 上有写到使用
.env的原因，大概如下：文件与代码分离，避免敏感信息提交到 Github 等开源社区，一般都会配置版本控制器忽略此文件；
形成统一的规范，用不同环境的配置文件也可以有类似的效果，但可能造成没有统一的命名在 A 项目中用了
LocalConfig.php在 B 项目中用了TestConfig.php，使用.env文件的话，新接触该项目的人员只要有看过框架的手册或接触过.env文件就可以清楚需要配置的环境变量有哪些；注：加载
.env文件有一定的性能开销，对性能要求很高的项目，最好在发布到线上生产环境的时候通过工具将.env文件合并到代码中。据一位大神说的，如果当你把laravel变成守护进程的时候，就非常容易出现很多问题。
我以上是说的全局常量。