laravel 为什么要大量使用env而不是普遍用的常量定义的方式呢？
闭关修行中......
题主理解错了，laravel并没有把常量写到env。
laravel的常量还是常量，而且一般在类内部。例如：
在解释这个问题之前，题主需要先区分环境变量（env） 配置信息（config） 常量（define） 的区别。
环境变量（env）
配置信息（config）
常量（define）
环境变量，顾名思义，是根据运行环境不同而不同的变量。例如临时文件目录 数据库账号密码 这些。
临时文件目录
数据库账号密码
配置信息，是代码中可切换部分的提取。例如我的程序里面，支持两种缓存方式file和redis，那么我可以直接写死在代码中。或者更好的写在配置中。不用去找到实现代码便可以切换缓存。
常量，顾名思义，是通常不会改变的变量，所以一般在代码中写死即可。这种东西一般是某个协议规定死的。在写请求类（Request）的时候，我们知道HTTP 请求中，有很多东西是规定死的，例如GET方法的字符串是GET，这个GET就是个常量。
GET
laravel是一个优雅的框架，所以很少使用全局的define来定义全局常量，而是更多的使用类常量。
我觉得：
语义化吧，本来就是和环境变量相关的东西，就类似restful一样
所以体现了它的优雅
1、常量是一次性的，值定义了就不能够修改，而env只是定义了一个环境变量，不一定就不重新赋值，两者的诉求不一样。用它自定义的封装可以少很多限制2、便于管理，因为它是存到$_SERVER里的，排查问题的时候可以直接罗列出来3、逼格高
因为可以根据你的实际环境快速切换项目配置开发->测试->生产不然就要去动配置文件，很麻烦，容易出错
参见The Twelve-Factor App。
其实通过环境变量来保存配置不是Laravel特有的实践。
@machenchi0207 是正解。项目一般耦合性越低，越利于扩展。当处于不同的环境如开发、测试、生产时，只要各自维护自己的env文件即可。如果都写在代码里，从开发推倒测试环境时，首先就是一个个去把代码里的配置信息改掉，运维测试人员会疯掉的:)
个人感觉应该是env可以很好地区分正式环境和开发环境，如果定义成常量的话。提交到正式环境还要修改。也可能会导致正式环境有问题。
最近也在看 Laravel，刚接触的时候也同样有这个疑问。Laravel 是用的 DotEnv 这个库，README 上有写到使用 .env 的原因，大概如下：
.env
文件与代码分离，避免敏感信息提交到 Github 等开源社区，一般都会配置版本控制器忽略此文件；
形成统一的规范，用不同环境的配置文件也可以有类似的效果，但可能造成没有统一的命名在 A 项目中用了 LocalConfig.php 在 B 项目中用了 TestConfig.php，使用 .env 文件的话，新接触该项目的人员只要有看过框架的手册或接触过 .env 文件就可以清楚需要配置的环境变量有哪些；
LocalConfig.php
TestConfig.php
注：加载 .env 文件有一定的性能开销，对性能要求很高的项目，最好在发布到线上生产环境的时候通过工具将 .env 文件合并到代码中。
据一位大神说的，如果当你把laravel变成守护进程的时候，就非常容易出现很多问题。
我以上是说的全局常量。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
题主理解错了，laravel并没有把常量写到env。
laravel的常量还是常量，而且一般在类内部。例如：
在解释这个问题之前，题主需要先区分
环境变量（env）配置信息（config）常量（define）的区别。环境变量，顾名思义，是根据运行环境不同而不同的变量。例如
临时文件目录数据库账号密码这些。配置信息，是代码中可切换部分的提取。例如我的程序里面，支持两种缓存方式file和redis，那么我可以直接写死在代码中。或者更好的写在配置中。不用去找到实现代码便可以切换缓存。
常量，顾名思义，是通常不会改变的变量，所以一般在代码中写死即可。这种东西一般是某个协议规定死的。在写请求类（Request）的时候，我们知道HTTP 请求中，有很多东西是规定死的，例如GET方法的字符串是
GET，这个GET就是个常量。laravel是一个优雅的框架，所以很少使用全局的define来定义全局常量，而是更多的使用类常量。
我觉得：
语义化吧，本来就是和环境变量相关的东西，就类似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变成守护进程的时候，就非常容易出现很多问题。
我以上是说的全局常量。