Vue项目生产环境解决跨域问题

一.前言

第一次写vue项目，开发完成。打包上线后，一访问，发现访问后端的请求全部报404.我就纳闷了，跨域问题我已经解决了，怎么就报错了。查阅资料，得知我解决的跨域仅适用于开发环境。

 

ememem...那好吧，开始解决生产环境的跨域问题

 

看到的大多数的解决方法：

（1）在config/dev.env.js下配置开发环境的API_ROOT

'use strict'
const merge = require('webpack-merge')
const prodEnv = require('./prod.env')

module.exports = merge(prodEnv, {
  NODE_ENV: '"development"',
  API_ROOT: '"/api"'   //这是新增的代码
})


（2）在config/prod.env.js下配置生产环境的API_ROOT

'use strict'
module.exports = {
  NODE_ENV: '"production"',
  API_ROOT: '"https://xxx/"'   //这是新增的代码
}
（3）在需要调用的地方

export const evidence_url = process.env.API_ROOT + '/' + '';  

//process.env.API_ROOT 根据不同的环境会返回给你不同的API_ROOT

因为导入webpack-merge不太方便。又查询了webpack-merge。

通常会用process.env.NODE_ENV === "development"，并且在package.json中设置环境变量来进行判断，不
过当文件大了或者页面需要判断的地方多了之后，配置文件就会充斥着大量三元表达式
。

可以考虑用webpack-merge将配置文件拆分为3个文件，一个是webpack.common.js，即不管是生产环境还是开发
环境都会用到的部分，以及webpack.product.js和webpack.dev.js, 并且使用webpack-merge来合并对象。

所以说，我的项目很简单，没有必要导入webpack-merge

其中：process.env.NODE_ENV 引起了我的注意

1. //默认 NODE_ENV 为环境变量名称

2. //可自行在 process.env 对象下定义需要使用的变量,在项目中可以根据

3. //不同的 env 值设置 defaultUrl 或者其他值

 上面的方法就相当于在main.js里加入下面这句话:

 Vue.prototype.baseUrl = process.env.NODE_ENV==="production"?"http://api.jzdisplay.com":"/api"

 但是http://api.jzdisplay.com，我不知道来自哪里。反正目前是不存在这样一个路径。我看了很多博客都没有说，我想这个路径应该是反向代理给出的，所以真正解决跨域问题的方法根本就不是上面的方法（与之类似的方法同理）。上面的方法解决的是，不同环境访问不同接口。

二、不同环境接口配置

main.js 中写入

 Vue.prototype.baseUrl = process.env.NODE_ENV==="production"?"http://192.168.0.2/show":"/api"

使用：

    async getdata() {
      try {
        var url=this.baseUrl+"/getShowData";
        const response = await this.$axios.get(url);
        ....
      } catch (error) {
        // 错误处理
      }
    }

当你开发测试时，请求数据会走代理路径，当上线时，请求数据会走真实路径（服务器提供的后端路径）

三.解决跨域

后来同事请教朋友，说访问路径直接写成原始的，不走代理。当然这么做，因为端口不同，依然会存在跨域。其实F12，数据是请求到的，但是依然没有显示并报跨域的错误。唉，我想明白了，上线跨域问题，应该是服务器解决的。

1、cros

因为大家使用的后端语言各不一样，得自己去查询怎么做了。

2.反向代理

 

四.请求cancle

哦对了，其中还有个小插曲

前端去请求后端，请求状态一会儿变成了cancled。原因是main.js中

 Vue.prototype.timeout = 500

timeout设置的太短了，还没访问到数据就超时了。

 

五、总结

虽然很笨地走了好些绕路，但处理这类问题，不再像之前一样晕乎晕乎了。文章写得有些乱，如果有什么不正确，欢迎各路英雄指正。