摘要：用于告知浏览器可以将预先检查请求返回结果缓存的时间，在缓存有效期内，浏览器会使用缓存的预先检查结果判断是否发送跨域请求。

作为一只前端菜鸟，跨域方面只懂得JSONP和CORS，并未曾深入了解。但随着春招越来越近，就算是菜鸟也要猛振翅膀。近几日仔细研究了跨域问题，写下这篇文章，希望对开发者们有所帮助。在读本文前，希望您对以下知识略有了解。

浏览器同源策略

nodejs

iframe

docker, nginx

因为浏览器的同源策略规定某域下的客户端在没明确授权的情况下，不能读写另一个域的资源。而在实际开发中，前后端常常是相互分离的，并且前后端的项目部署也常常不在一个服务器内或者在一个服务器的不同端口下。前端想要获取后端的数据，就必须发起请求，如果不做一些处理，就会受到浏览器同源策略的约束。后端可以收到请求并返回数据，但是前端无法收到数据。

跨域可以大概分为两种目的

前后端分离时，前端为了获取后端数据而跨域

为不同域下的前端页面通信而跨域

CORS是一个跨域资源共享方案，为了解决跨域问题，通过增加一系列请求头和响应头，规范安全地进行跨站数据传输

客户端只需按规范设置请求头。

服务端按规范识别并返回对应响应头，或者安装相应插件，修改相应框架配置文件等。具体视服务端所用的语言和框架而定

一个spring boot项目中关于CORS配置的一段代码

HttpServletResponse httpServletResponse = (HttpServletResponse) response;
        String temp = request.getHeader("Origin");
        httpServletResponse.setHeader("Access-Control-Allow-Origin", temp);
        // 允许的访问方法
        httpServletResponse.setHeader("Access-Control-Allow-Methods", "POST, GET, PUT, OPTIONS, DELETE, PATCH");
//         Access-Control-Max-Age 用于 CORS 相关配置的缓存
        httpServletResponse.setHeader("Access-Control-Max-Age", "3600");
        httpServletResponse.setHeader("Access-Control-Allow-Headers",
                "Origin, X-Requested-With, Content-Type, Accept,token");
        httpServletResponse.setHeader("Access-Control-Allow-Credentials", "true");

jsonp的原理就是借助HTML中的

后端代码(nodejs)

var querystring = require("querystring");
var http = require("http");
var server = http.createServer();

server.on("request", function(req, res) {
    var params = querystring.parse(req.url.split("?")[1]);
    var fn = params.callback;

    // jsonp返回设置
    res.writeHead(200, { "Content-Type": "text/javascript" });
    var data = {
        user: "xbc",
        password: "123456"
    }
    res.write(fn + "(" + JSON.stringify(data) + ")");

    res.end();
});

server.listen("8080");
console.log("Server is running at port 8080...");

在该例子中，前台收到的res是这样的

前端页面是这样的

JSONP既是利用了，那么就只能支持GET请求。其他请求无法实现

既然浏览器有同源策略限制，那我们把前端项目和前端要请求的api接口地址放在同源下不就可以了？再结合web服务器提供的反向代理，便可以在前端和后端都不做配置的情况下解决跨域问题。

后端真实后台地址：http://xxx.xxx.xxx.xxx:8085 后台地址使用tomcat部署的spring boot项目 名为gsms_test

nginx服务器地址: http://xxx.xxx.xxx.xxx:8082

tomcat和nginx都是用docker架设的，做了端口转发

使用条件：开发环境为linux系统

nginx /etc/nginx/conf.d/default.conf配置代码如下

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        # root   /usr/share/nginx/html/dist; # 前端项目路径
        # index  index.html index.htm;
        proxy_pass http://localhost:8001/; # 前端本机地址，实现自动更新
        autoindex on;
        autoindex_exact_size on;
        autoindex_localtime on;
    }

    location /gsms_test/ {
        proxy_pass 后端真实地址;
    }

    

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ .php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ .php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache"s document root
    # concurs with nginx"s one
    #
    #location ~ /.ht {
    #    deny  all;
    #}
}

window.name是浏览器中一个窗口所共享的数据，在不同的页面（甚至不同域名）加载后依旧存在（如果没修改则值不会变化），并且可以支持非常长的 name 值（2MB）。比如 a域的某页面想获取b域某页面的数据，可以在b域中修改window.name值，a域切换到b域再切回来即可得到b域的window.name值。可是我们在开发中肯定不想页面切来切去，所以就要结合iframe来实现。

a 域代码如下

server A

b 域代码

  
server 2

由于受同源策略限制，父页面获取跨域的iframe页面的信息不全，所以要在iframe的window.name被B域修改后，转为A域下的任一页面(该一面不得修改window.name)，在进行获取。

由于iframe与父页面相互访问也受同源策略限制，所以要借助一代理页面实现跨域。

个人认为有些麻烦，若有兴趣请看前端如何用代理页面解决iframe跨域访问的问题？

以上几种皆是本人用过或测试过的跨域方法，还有postMessage，WebSocket等跨域方法由于从未接触不做说明。在项目中具体使用那些方法还需具体考虑各种问题

经验 跨域方案

CORS——跨域请求那些事儿

前端如何用代理页面解决iframe跨域访问的问题？

前端常见的跨域解决方案(全)

CORS与服务器反向代理的优劣对比

图解正向代理、反向代理、透明代理

本文如有错误，欢迎指出
本人邮箱 xbc18304999858@gmail.com