vuecli2.x版本构建的项目如何配置环境变量

vuecli2.x构建的项目目录和vuecli3.x/4.x是不同的
在vuecli2.x版本构建的项目根目录中有build和config文件夹如下：

我们接下来只讲vuecli2.x是如何配置环境变量的
一般会划分哪些环境呢？
开发环境development，测试环境test，正式环境production
为什么要划分？
开发的时候我们访问接口地址都是访问他们的ip地址；开发完了项目打包到放到测试服务器，你的接口地址要变成测试地址；上线了接口地址又要改成正式地址；总不能每次手动切换把，而且不仅仅是接口地址，还有可能有其他的东西也需要根据不同的环境设置不同的值
如何配置环境变量？
配置环境变量很简单，我们初始化项目的时候，脚手架已经为我们配置好了最基本的环境变量，我们看config文件夹中

已经设置了一个NODE_ENV，然后我们在项目组件中或者js文件中直接通过process.env.NODE_ENV拿到值，然后根据这个值，去做我们想做的事情，当然也不仅仅只有NODE_ENV，你还可以设置任何你想设置的。
这个时候我们有没有想过，为什么在组件中或者js文件中直接通过process.env就能访问呢？
来看看我们一开始执行脚本把
运行项目执行npm run dev
打包项目执行npm run build

 "scripts": {
    "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
    "start": "npm run dev",
    "lint": "eslint --ext .js,.vue src",
    "build": "node build/build.js"
  },

里面的scripts字段是一个对象。它的每一个属性，对应一段脚本。比如，build命令对应的脚本是node build/build.js。npm 脚本的原理非常简单。每当执行npm run，就会自动新建一个 Shell，在这个 Shell 里面执行指定的脚本命令，因此，只要是 Shell（Bash）可以运行的命令，就可以写在 npm 脚本里面。
所以node build/build.js，就是在shell里面用node去执行build文件夹中的build.js文件。
我们抽取build.js文件中的一段代码

const webpackConfig = require('./webpack.prod.conf')

他是不是引入了webpack.prod.config.js文件。

再看webpack.prod.config.js文件中的一块代码。

const env = require('../config/prod.env')

他是不是引入了config文件夹中prod.env.js文件

再看下面这段代码

 plugins: [
 // http://vuejs.github.io/vue-loader/en/workflow/production.html
 new webpack.DefinePlugin({
      'process.env': env
    }),
 ]

他是不是将env也就是prod.env.js导出的模块应用了
这个时候肯定好奇new webpack.DefinePlugin这是啥？我在学的时候也好奇DefinePlugin
说白了

new webpack.DefinePlugin({
      'process.env': env,
      a:JSON.stringify('aaa')
    }),
 ]

我们在组件或者js文件中访问process.env是因为将process.env整体作为全局变量，因为env又是一个对象，所以process.env.NODE_ENV
我们还可以直接访问a，得到’aaa‘
但是一般我们只添加个’process.env’，需要的key=value都写在env对象中，也就是在dev.env.js或者prod.env.js文件中

同理
npm run dev 其实就是通过webpack-dev-server在本地给我们起了一个服务。也是通过脚本执行build/webpack.dev.conf.js文件
他里面也写了

 new webpack.DefinePlugin({
      'process.env': require('../config/dev.env')
    }),

你开发的时候要用哪些变量就写在dev.env.js中就行了
以上只是解释了初始化项目之后最基本的配置

接下来讲讲打测试包和打正式包
不管是测试还是正式环境变量都是production，我们只不过为什么区分他定义了test和prod
看下面

"build:test": "cross-env NODE_ENV=production env_config=test node build/build.js",
"build:prod": "cross-env NODE_ENV=production env_config=prod node build/build.js",

我们可以自己去配置脚本
然后打测试包，执行npm run build:test，这个时候要一个细节，cross-env是干什么的，cross-env是用来跨平台设置环境变量的，NODE_ENV=production env_config=test就是我们手动设置的环境变量
注意：这儿设置的环境变量和DefinePlugin设置的环境变量要区分，他们可不是一样的。
通过cross-env设置的环境变量是在node环境中设置的环境变量。通过process.env去访问，这个process在node中是真实存在，process.env可不止有NODE_ENV=production env_config=test，还有很多很多其他的变量，说白了就是编译时生成的变量，仅编译时可用
而DefinePlugin设置的环境变量是运行时的环境变量，项目在运行，代码中随处可访问

为什么会搞个cross-env来设置环境变量呢？
之前我们也说了在webpack.prod.conf.js中直接是引入的prod.env.js
const env = require(’…/config/prod.env’)
但我们要区分测试还是正式，所以再新增一个test.env.js的文件，
这个时候要改造 const env = require(’…/config/prod.env’)

 const env = require('../config/' + process.env.env_config + '.env')

我们可以通过process.env.env_config去区分引入test还是prod
注意哈，刚刚也说了执行脚本的时候再node环境创建了env_config变量，node执行build.js文件的时候，就可以在js文件中通过process.env访问
这个应该能理解（比如写一个在一个js文件中直接console.log(proceess.env)然后再控制台用node执行这个js文件，就明白了）
npm run build:prod也是同理的
这个时候是不是就已经区分了不同的环境了
还没完
如果我想在xx.env.js文件中我们要设置的环境变量搞个动态的
比如

 module.exports = {
 	BASE_API: `'${request_url}'`
 }

这个BASE_API的值不能写死，这时候可能会想，不是已经划分不同的环境了吗，已经很灵活了，为什么还要设置动态的环境变量？
正常是写死就好了？但是我们公司不是？所以我这儿就再写点
前面不是已经说了在脚本出设置node环境变量吗？打个部分，我们设置成这样

"build:test": "cross-env NODE_ENV=production env_config=test request_url=https://111.222.com  node build/build.js",

然后再test.env.js中这样写

const {request_url = ""} = process.env;
 module.exports = {
    NODE_ENV: '"production"',
    BASE_API: `'${request_url}'`
};

这样就设置成动态的了
还有个操作，
如果在我们本地直接运行npm run build:test，执行下面脚本是没问题的

"build:test": "cross-env NODE_ENV=production env_config=test request_url=https://111.222.com  node build/build.js"

但是这段脚本可以被替换，request_url可以改成其他的
这就是为什么我说环境变量可以设置成动态的原因，更加灵活，总结这个也是因为最近才遇到的，也是思考了许久想清楚的