84669인 학습
152542인 학습
20005인 학습
5487인 학습
7821인 학습
359900인 학습
3350인 학습
180660인 학습
48569인 학습
18603인 학습
40936인 학습
1549인 학습
1183인 학습
32909인 학습
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变成守护进程的时候,就非常容易出现很多问题。
我以上是说的全局常量。
题主理解错了,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变成守护进程的时候,就非常容易出现很多问题。
我以上是说的全局常量。