laravel 为什么要大量使用env而不是普遍用的常量定义的方式呢？

Question

laravel 为什么要大量使用env而不是普遍用的常量定义的方式呢？

Answer 1

题主理解错了，laravel并没有把常量写到env。

laravel的常量还是常量，而且一般在类内部。例如：

在解释这个问题之前，题主需要先区分环境变量（env） 配置信息（config） 常量（define） 的区别。

环境变量，顾名思义，是根据运行环境不同而不同的变量。例如临时文件目录 数据库账号密码 这些。

配置信息，是代码中可切换部分的提取。例如我的程序里面，支持两种缓存方式file和redis，那么我可以直接写死在代码中。或者更好的写在配置中。不用去找到实现代码便可以切换缓存。

常量，顾名思义，是通常不会改变的变量，所以一般在代码中写死即可。这种东西一般是某个协议规定死的。在写请求类（Request）的时候，我们知道HTTP 请求中，有很多东西是规定死的，例如GET方法的字符串是GET，这个GET就是个常量。

laravel是一个优雅的框架，所以很少使用全局的define来定义全局常量，而是更多的使用类常量。

Answer 2

我觉得：

语义化吧，本来就是和环境变量相关的东西，就类似restful一样

所以体现了它的优雅

Answer 3

1、常量是一次性的，值定义了就不能够修改，而env只是定义了一个环境变量，不一定就不重新赋值，两者的诉求不一样。用它自定义的封装可以少很多限制
2、便于管理，因为它是存到$_SERVER里的，排查问题的时候可以直接罗列出来
3、逼格高

Answer 4

因为可以根据你的实际环境快速切换项目配置
开发->测试->生产
不然就要去动配置文件，很麻烦，容易出错

Answer 5

参见The Twelve-Factor App。

其实通过环境变量来保存配置不是Laravel特有的实践。

Answer 6

@machenchi0207 是正解。
项目一般耦合性越低，越利于扩展。当处于不同的环境如开发、测试、生产时，只要各自维护自己的env文件即可。如果都写在代码里，从开发推倒测试环境时，首先就是一个个去把代码里的配置信息改掉，运维测试人员会疯掉的:)

Answer 7

个人感觉应该是env可以很好地区分正式环境和开发环境，如果定义成常量的话。提交到正式环境还要修改。也可能会导致正式环境有问题。

Answer 8

最近也在看 Laravel，刚接触的时候也同样有这个疑问。Laravel 是用的 DotEnv 这个库，README 上有写到使用 .env 的原因，大概如下：

1. 文件与代码分离，避免敏感信息提交到 Github 等开源社区，一般都会配置版本控制器忽略此文件；

2. 形成统一的规范，用不同环境的配置文件也可以有类似的效果，但可能造成没有统一的命名在 A 项目中用了 LocalConfig.php 在 B 项目中用了 TestConfig.php，使用 .env 文件的话，新接触该项目的人员只要有看过框架的手册或接触过 .env 文件就可以清楚需要配置的环境变量有哪些；

注：加载 .env 文件有一定的性能开销，对性能要求很高的项目，最好在发布到线上生产环境的时候通过工具将 .env 文件合并到代码中。

Answer 9

据一位大神说的，如果当你把laravel变成守护进程的时候，就非常容易出现很多问题。

我以上是说的全局常量。