相亲交友源码开发，解决跨域问题的可行性方案

作为相亲交友源码的前端开发，你还在为解决跨域而烦恼吗？
跨域怎么产生就不在细说了
这里我推荐这两种相亲交友源码跨域方式，其它的跨域方式都还有很多但都不推荐，主流的也就这两种方式。
解决方案如下：
在这里插入图片描述

方案一：cors~

cors 全称为 Cross Origin Resource Sharing（跨域资源共享）。这种方案对于相亲交友源码前端来说没有什么工作量，和正常发送请求写法上没有任何区别，工作量基本都在相亲交友源码后端这里。
每一次请求，浏览器必须先以 OPTIONS 请求方式发送一个预请求（也不是所有请求都会发送 options， cors），通过预检请求从而获知服务器端对跨源请求支持的 HTTP 方法。在确认服务器允许该跨源请求的情况下，再以实际的 HTTP 请求方法发送那个真正的请求。
推荐的原因是：只要第一次配好了，之后不管有多少接口和项目复用就可以了，一劳永逸的解决了相亲交友源码跨域问题，而且不管是开发环境还是正式环境都能方便的使用。

但总有后端觉得麻烦不想这么搞，那纯前端也是有解决方案的。

方案二：proxy+nginx

在 dev 开发模式下可以下使用 webpack 的 proxy 使用也是很方便，但这种方法在生产环境是不能使用的。在生产环境中需要使用 nginx 进行反向代理。不管是 proxy 和 nginx 的原理都是一样的，通过搭建一个中转服务器来转发请求规避相亲交友源码跨域的问题。

开发环境

本地开发的话如果你是框架之类的，直接使用proxy进行代理即可
如果没有使用框架以及webpack之类的，最简单的就是禁用谷歌浏览器的安全策略

 devServer: {
    proxy: {
      '/common-backend': {
        target: `http://url:port/`,
        changeOrigin: true
      }
    }
  },

生产环境

生产环境的话还是比较推荐nginx的

nginx

那么相亲交友源码前端在代码里只需要访问/mall_war/*.do就可以，默认发的是部署服务器的ip来访问
然后再nginx里配置如下

server {
    listen       8066;
    server_name  commonFronted;
    # 项目静态资源目录
    location / {
        alias     /xxx/dist;
        index     index.html;
    }

    location ^~/mall_war/ {
        proxy_pass http://localhost:8089/mall_war/;
        proxy_set_header  Host $host;
        proxy_set_header  X-Real-IP $remote_addr;
        proxy_set_header  X-Forwarded-Proto https;
        proxy_set_header  X-NginX-Proxy true;
        proxy_buffers 256 4k;
        proxy_max_temp_file_size 0k;
        proxy_connect_timeout 30;
        proxy_send_timeout 60;
        proxy_read_timeout 60;
        proxy_next_upstream error timeout invalid_header http_502;            
    }
}