摘要：用于告知瀏覽器可以將預先檢查請求返回結果緩存的時間，在緩存有效期內，瀏覽器會使用緩存的預先檢查結果判斷是否發送跨域請求。

作為一只前端菜鳥，跨域方面只懂得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