前言
env 是当前一个主流趋势，也是目前各大框架主推的动态管理不同部署环境的配置文件解决方案，比如 TP 、LV、Yii等,我做一个整理,把我对它的理解和解决了什么痛点做一个梳理:
1
在 2010 年左右框架开发还不是主流,很多项目都是自己封装类库,比如 MySQL 的连接和查询,需要自己编写类库,就把账号、密码这些参数硬编在代码里面(当然今天的思维回头去看，会觉得不合理，但是在那个时代无疑是正确的方式)
而后做部署和修改密码等事情的时候，总是要去找对应文件里面 对应硬编数据的位置，后来意识到了它的不便，就把这些所谓的 动态的、有可能改变的数据变量做成 配置文件的方式，这个思想在很大程度了得到了普及，各大框架在配置文件这个模块也是会花各种心思去尽可能方便优雅的满足各个场景。
但是现在互联的发展、需求不断复杂、技术不断迭代，各种第三放插件不断普及，需要的配置文件也越来越多：数据库配置、缓存配置、项目配置、业务逻辑配置、日志配置……有一天会发现 TMD 这么多配置文件，而且还要不断的在开发环境、测试环境、正式环境来回切换,项目多了、协作的人多了、配置文件多了自己随时都处在蒙圈的状态
然而很多人的解决方案是不管它是什么,只有是配置文件夹下的文件,不管37 21 全部忽略掉这也是最简单粗暴直接的方式,但是细想你会觉得合理吗? 因为手被蚊子咬了一个包,痒的难受,把手砍了? 这时候 env 思想就出现了,不要砍手,哪里痒,我们治理那里
2
以 database.php 数据库配置文件为例：这个配置文件下面其实有 10 多个配置信息，其实真正变动的只有 3 个 hostname、username、password 因为部署环境不同,要去配置不同的参数，因为这 3 个数据的变化,被迫把整个 database.php文件忽略了? 这样的文件还要很多 cache.php、redis.php...
我们换一个思路，我们把这些配置文件里面,因为部署环境原因需要动态改变的变量 解耦抽离出来，全部放在 env 文件来集中统一管理呢：
- 当需要需改配置时第一反应就是去找 env ，而不是四处去找 database.php、cache.php redis.php....
- 各配置文件中只是因为部署环境不同，需要改变的局部变量去动态加载 env 配置，同时有效的解决了精准忽略变量，而不是 宁可错杀一万的方式 忽略整个文件
3
略配置文件，我们 忽略 env 文件实质是，精准的 忽略变量 而不是文件，同时我在 env 文件里面标识一个当前部署环境变量
APP_STATUS = dev 这个变量参数有 dev(本地开发环境)、test（测试环境）、master（正式环境）
以对接 CA 为例：在开发环境 调有 CA 公司的测试环境接口地址 ，在测试环境调有 CA 公司测试环境接口，在正式环境调有 CA 公司正式接口
| 我们的环境 | 支付宝 公司环境(第三方环境) |
|---|---|
| 本地开发环境 | 测试环境 |
| 测试环境 | 测试环境 |
| 正式环境 | 正式环境 |
我们会因为这个常规需求去搞两套配置吗？去多搞 3 个忽略文件吗？我们只需要读取 env 当前环境变量，当前部署环境值就知道现在所处部署环境，然后通过多态、条件语句、接口类等方式完美的解决了 各个部署环境下的兼容问题
这是我整理的 env 的优势以及我对它的理解：
- 精准忽略变量而不是文件，让忽略文件变得更有价值而不是 宁可错杀一万的方式 忽略整个文件
- 集中统一管理有且只有一个动态位置
- 兼容动态读取不同环境需要的业务逻辑走向
