实现vue项目通用配置环境管理

在项目开发中，如果需求将同一套代码部署到多台服务器上，并且代码上的区别只改变后端url指向地址。

如何做这个时候需要思考有哪些解决方案：

一、初版配置

最开始按照最简单的思维方式，针对每一个后端地址进行单独打一个包，这个做法确实能解决问题，但是如果需要更新代码，那么针对每个环境每次都需要重新的打包再上传代码的动作，其实是比较耗时且不友好，如果更新上线后发现地址写错了那么就需要再次打包上传。

1、代码案例

1、首先看下vue环境配置是做的，一般在根节点目录下新建文件：.env.development（开发环境）、.env.production文件（生产环境） 在.env.development（开发环境）文件下写入

NODE_ENV='development'
//  var ACTION_PATH = "http://192.168.0.121/ysapi";
// var ACTION_PATH = "http://192.168.0.121/onestopapi";
  var ACTION_PATH = "http://192.168.0.72:55559";//

在.env.production（生产环境）文件下写入

NODE_ENV='production'
ACTION_PATH = "http://192.168.7.107:8080";//
//ACTION_PATH = "http://192.168.0.72:8300";
//ACTION_PATH = "http://192.168.0.72:55559";

使用调用该变量的时候，通过process.env.的方式使用，例如下面我要封装axios请求的时候：

var api = axios.create({
    baseURL:process.env.ACTION_PATH,//请求后端地址
    timeout: 7000,//请求超时
    withCredentials: true, // 是否发送 cookie
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
    },
});

2、代码解释

process.env对象是Node.js提供的一个全局对象，用于访问当前Node.js进程的环境变量。在Vue项目中，我们可以通过这个对象来获取在启动项目时设置的环境变量。

在Vue项目中，我们通常会有一些配置是根据不同的环境来改变的，比如API的地址，在开发环境中我们可能会用到本地的API，在生产环境中则需要用到线上的API。

这时我们可以通过设置环境变量的方式来实现这种需求。在Vue项目中，我们可以在项目根目录下创建一个.env文件，然后在这个文件中设置环境变量

自此最简单的将一套代码部署在不同服务器的方案就处理了，那就是每次都去改变ACTION_PATH值然后再重新打包部署更新上线。

二、优化配置

过一段时间，觉得刚才的那种方式太过痛苦，每次测试上线需要改变两个文件的url，有可能用错了后端环境，并且两个文件对应的开发环境url和生成环境url都是通过备注的方式来记录可能会混乱，对这个环境配置做优化。

这时看到下面一段文档内容：

在 Vue CLI 创建的项目中，process.env.NODE_ENV 的值会根据你运行的命令自动设置。例如，如果你运行 npm run serve（或 yarn serve），那么 process.env.NODE_ENV 的值会被设置为 "development"；如果你运行 npm run build（或 yarn build），那么 process.env.NODE_ENV 的值会被设置为 "production"。

1、代码案例

思路设计一个配置文件，通过不同的变量管理不同的环境。利用Node.js设置的环境变量process.env.NODE_ENV确定当前处于哪种模式（开发模式、测试模式还是生产模式）。

在src/api文件中创建config.js文件，文件中写

export default {
    baseUrl: {
            development: 'http://localhost:8081/muyouyu',// 开发环境
            production: 'http://localhost:8080/onestop',// 正式环境
    },
    newbaseUrl: {
            development:'http://192.168.0.72:55555',// 开发环境
            production: 'http://192.168.0.72:55559',// 正式环境
    },
      //更多配置  ...	
}

同样以刚才封装axios请求的案例：

import config from '@/api/config.js'
var api = axios.create({
    baseURL: config.baseUrl[process.env.NODE_ENV],//请求后端地址
    timeout: 7000,//请求超时
    withCredentials: true, // 是否发送 cookie
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
    },
});

2、代码解释

上面的案例代码分两个模块：

1、配置文件，它导出了一个对象，对象中有一个baseUrl属性，这个属性的值也是一个对象，包含了两个属性：development和production。这两个属性分别对应了开发环境和生产环境的baseUrl。

2、axios请求引用上述配置文件。config.baseUrl[process.env.NODE_ENV]这段代码的意思是，根据当前的环境变量process.env.NODE_ENV的值（development或production）来获取对应环境的baseUrl。

三、最终方案

随着项目部署的环境越来越多，使用配置变量也越来越多，同时采用上面方案也没有根本上解决最开始的那问题，自此想到了我上家公司的react开发的sass平台，在public文件夹创建一个congfig.js文件，将配置参数都写在这个（public文件打包编译时不会修改文件内容，会原封不动保留）；在此基础上将congfig.js的配置项挂载到浏览器window对象，页面上调用，通过window.appConfig的方式获取url。

1、代码案例

说干就干，根据刚才的思路写案例demo

第一段代码是在public文件夹创建一个congfig.js文件，在全局作用域内定义一个名为window.appConfig的对象。该对象包含该应用的配置信息，例如应用名称、版本、描述、图标以及配置文件地址等信息。

window.appConfig = {
    // 应用名称
    appName: 'vue-admin-beautiful',
    // 应用版本
    appVersion: '1.0.0',
    // 应用描述
    appDescription: 'vue-admin-beautiful',
    // 应用图标
    appLogo: require('@/assets/logo.png'),
    // 应用图标高清

    // 配置文件地址
    configBaseUrl:'https://apitest.xhsbds.com/'//动态环境
  }

第二段代码是在主入口文件main.js中导入了上一段代码中定义引用的config.js文件，即应用的配置信息。

import '../public/config.js'

第三段代码是创造了一个新的 Axios 实例，然后设置了这个实例的请求拦截器。在每次实例发送请求之前，都会先进入请求拦截器。在请求拦截器中，将配置的 base URL 更新为全局配置的 configBaseUrl，也就是将请求的后端地址指向为用户自定义的地址。

var api = axios.create({
    timeout: 7000,//请求超时
    withCredentials: true, // 是否发送 cookie
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
    },
});


// 请求拦截器
api.interceptors.request.use(
    config => {
        config.baseURL = window.appConfig.configBaseUrl;//请求后端地址
        return config;
    },
    error => {
        return Promise.reject(error);
    }
);

2、代码解释

为什么这次的axios配置没有放在create中声明baseURL后端路径呢？其实也可以，主要是为了方便调试，在控制台更改请求地址后，页面可以实时看到最新请求路径效果。总结来说，这三段代码将用户自定义的配置信息（包括后端地址）注入到所有的后端请求中配置更加灵活。

3、归纳总结

采用这种方式动态设置 base URL 的好处主要有以下几点：

1. 灵活性：将 base URL 抽离出来作为配置，可以随时改变请求的服务器而不需要修改代码，只需要修改配置文件即可。
2. 统一管理：如果项目中有大量的后端请求，统一将 base URL 作为配置进行管理，可以避免在每个请求的 URL 中都包含相同的 base URL。
3. 环境切换方便：在开发过程中，常与多个服务器系统进行交互，如测试环境、预发环境、生产环境等不同环境下的服务器。将 base URL 设置在配置文件中，可以快速在这些环境间切换。
4. 便于维护：项目迭代过程中，如果服务端的URL地址或者端口有变化，只需要去修改配置文件就可以了，无需搜索整个项目的网络请求去修改，节约时间并且易于维护。