.env.example

因 ^.env 不会被纳入版本控制器中，所以本地的 ^.env 内添加变量时 必须 同步到 ^.env.example 中，以免影响其他项目参与者的工作。

变量存储位置

假如我们有两个『CDN 域名』的变量，在 Laravel 中有以下几种方法：

• 1. 硬代码，直接写死。- ❌ 可维护性低
• 2. 写死在^{config/app.php} 文件中。- ❌ 无法区分环境进行配置
• 3. 存储在 ^.env 文件中，使用 ^env() 方法直接读取。- ❌ 虽然解决了环境变量问题，但是不推荐。
• 4. 存储在 ^.env 和 ^{config/app.php} 文件中，然后使用 ^config() 函数来读取。- ✅ 最佳实践

第一种方法是最古老的方法，代码可维护性极低，一旦域名变更就只能全局替换。
第二种方法无法区分环境，例如本地使用开发环境域名测试，线上才是正式的 CDN 域名。
第三种方法虽然解决了环境变量的问题，并且也具备一定的灵活性，但是不够灵活，假如网站流量巨大，需要配置几个 CDN 域名，使其在加载静态资源时随机支配域名，这种做法就无法满足需求了。
第四种方法既支持环境变量，又具备极高的灵活性，假如遇到同样的 CDN 多域名随机问题，你只需要写一个辅助方法，然后在 ^{config/app.php} 中调用即可，不需要动任何一行业务逻辑代码。

代码示例：

^.env 中设置：

CDN_DOAMIN=cdn.domain.com

^{config/app.php} 中设置：

'cdn_domain' => env('CDN_DOMAIN', null)

程序中两种获取 ^相同配置 的方法：

• 1. ^{env('CDN_DOAMIN')}
• 2. ^{config('app.cdn_domain')}

在此统一规定：所有程序配置信息 必须 通过 ^config() 来读取，所有的 ^.env 配置信息 必须 通过 ^config() 来读取，绝不再配置文件以外的范围使用 ^env() 。

有何优势

这样做有以下几个优势：

• 1. 定义分明，^config() 是配置信息，^env() 只是用来区分不同环境；
• 2. 统一放置于 ^config 中，还可以利用框架的 配置信息缓存功能 来提高运行效率；
• 3. 代码健壮性，^config() 和 ^env() 之上多出来一个抽象层，会使代码更加健壮，更加灵活。

注：Laravel 5.2 以后的官方文档也提倡此用法。