Vueproxy解决跨域问题的完整解决方案---和解决沿途可配置链接方案的问题很好。最近因为项目问题，需要协助其他组搭建前端，所以需要解决Vue程序的跨域问题。但是网上找的解决办法有点片面。整体解决后，我写了一个集成版的解决方案。内容可能过长或冗余，希望大家按需使用。0.跨域问题的发生当浏览器从一个域名的网页向另一个域名请求资源时，域名、端口、协议的任何差异都是跨域的。在后端处理的情况下，一般会根据请求判断是否允许调用，在响应头中加入Access-Control-Allow-Origin，这样通过非法渠道的服务就无法获取到我的数据。一开始是完美的，但是在实际工作中，跨域是浏览器的策略，可以拿到数据，但是浏览器不允许，跟后台也没有关系。毕竟后台已经把数据发过来了，你也没用！而且，技术水平参差不齐的开发人员使这个问题更加荒谬。再者，如果真的不允许其他用户访问，还不如后台直接判断域名返回ERROR，这不比跨域安全100倍。跨域问题表现为1、为什么代理可以解决跨域问题？值返回到当前网页。不是web服务访问代理，而是代理检测web服务内部的接口服务。当符合条件的服务出现时，代理拦截它并返回结果而不是web服务。2.测试环境代理的配置方案在测试环境中，代理是借助webpack来完成的。网上查询的解决方案大多都是这部分的配置方法。（可能大部分人，在开发过程中只是处理跨域问题，不需要自己参与部署。）这里是我的代理配置，具体可以查看webpack或者网上的解决方案。proxy:{"/api":{target:"http://192.168.146.49:8081",//接口地址ws:true,//是否开启websocketschangOrigin:true,//允许跨域Originsource127.0.0.1:9000pathRewrite:{"^/api":""//请求时使用这个/api前缀}}}那么这是什么意思呢？当网页访问localhost:8080/api/xxxxx/xxx接口时，webpack会识别这是一个外部接口，访问http://192.168.146.49:8081/xxxxx/xxx并返回结果（一开始很天真，后来配置agent，会自动解决前面程序同源的问题，不好用，我觉得是配置错误。）所以axiosaccess部分也需要修改，因为前面的axios直接访问对应的地址，不是这个。机器地址（一开始没看懂，找了半天也没人说axios需要修改。严重怀疑很多人拿到现成的程序只需要修改本地代理地址，所以这部分我压根没提）修改前importaxiosfrom"axios";importvuefrom"vue";//import来自"qs"的qs;axios.defaults.withCredentials=false;axios.defaults.headers.post["Content-Type"]="application/json";//配置请求头letBASE_URL=Vue.prototype.BASE_URL;functiongetUrl(){returnVue.prototype.BASE_URL;}exportconstPOST=(url,param)=>{if(BASE_URL==undefined){BASE_URL=getUrl();//让参数=参数；returnaxios.post(`${BASE_URL}${url}`,param).then(res=>res.data);}else{//让参数=参数；returnaxios.post(`${BASE_URL}${url}`,param).then(res=>res.data);}};修改后importaxiosfrom"axios";constBASE_URL="/api";axios.defaults.withCredentials=false;axios.defaults.headers.post["Content-Type"]="application/json";//配置请求头exportconstGET=(url,param)=>{returnaxios.get(`${BASE_URL}${url}`,param).then(res=>res.data);};exportconstPOST=(url,param)=>{返回轴os.get(`${BASE_URL}${url}`,参数).then(res=>res.data);};其中修改前对BASE_URL的操作，之前服务的动态配置服务地址方案使用代理后，这部分就不用再做了（通过代理对应实际接口地址）。axios访问/api/XX/xxx时，会添加网页地址localhost:8080/api/XX/xxx，替换成webpack代理下的http://192.168.146.49:8081/XX/xxx结果3、服务器环境下代理的配置方案。在本地调试下，webpack会帮你完成脏活累活。打包后，服务器上没有webpack。代理应该做什么？查了一下，发现ngnix是网上最流行的方案。简单实用，轻量级，以后还可以用来做负载均衡，我就用着，用着别人咳咳。ngnix有多轻量级，下载下来，更改配置文件，双击运行OK，nginx-1.16.1confnginx.conf是配置文件中server的花括号，听90；服务器名称本地主机；#charsetkoi8-r;#access_loglogs/host.access.logmain;rootE:\dist;#vue项目打包后的dist位置/{try_files$uri$uri/@router;#需要指向后面的@router否则vue路由会出现在nginx的Refresh出现404indexindex.htmlindex.htm;}location@router{重写^.*$/index.htmllast;}location/api{重写^.+api/?(.*)$/$1break;#可选参数，常规验证地址包括uwsgi_params；#可选参数，uwsgi是服务端与服务端应用程序之间的通信协议，指定如何将请求转发给应用程序，并返回proxy_passhttp://192.168.146.49:8081；#这里改成你自己的请求地址，必填}其中listen是部署的端口，不能和其他程序冲突。server_name为部署的urlroot，即vue程序打包后的文件位置。locationlocation@router匹配Vue的路由配置项location/api是ngnix的代理。含义与测试环境相同。一切配置完成后，点击ngnix.exe程序启动。4.解决沿途的可配置链接问题，和之前的可配置解决方案。因为我们之前的产品产品化，需要部署到多个站点，所以需要修改服务对应的接口地址。所以我之前在配置文件里写了一个BASE_URL，在启动项目的时候存到Vue.prototype.BASE_URL中。代码如下：axios.get("./config.json").then(res=>{//基址Vue.prototype.BASE_URL=res.data.BASE_URL;newVue({router,store,render:h=>h(App)}).$mount("#app");});上面调用axios时的scheme我已经有了，就不贴了。当时，我觉得这个计划很完美。但是在配置了代理之后，突然想到了。以后不仅需要直接修改ngnix配置文件中的代理地址，而是需要重启ngnix。现在想来终于知道为什么之前可配置base_url的方案那么少了，因为这是使用代理时的伪需求。写下来，真的觉得学无止境，还有很多不懂的地方，以后要增加知识储备。
