前兩個tab頁是項目本身的，第三個是iframe嵌套的以前的一個項目（獨立的功能）；
做好后，第三個tab一直沒怎么用。最近突然有用戶要用，但是部分人的界面白屏。
排查發現是接口請求失敗導致的JS報錯，失敗原因是登錄后cookie存儲失敗。
原因：
Chrome 80版本開始，瀏覽器的 Cookie 新增加了一個SameSite屬性，用來防止 CSRF 攻擊和用戶追蹤。並將未聲明 SameSite 值的 Cookie 默認設置為SameSite=Lax Cookie。
HTTP
一般我們都會說 “HTTP 是一個無狀態的協議”，不過要注意這里的 HTTP 其實是指 HTTP 1.x，而所謂無狀態協議，簡單的理解就是即使同一個客戶端連續兩次發送請求給服務器，服務器也識別不出這是同一個客戶端發送的請求，這導致的問題就比如你加了一個商品到購物車中，但因為識別不出是同一個客戶端，你刷新下頁面就沒有了……
Cookie
為了解決 HTTP 無狀態導致的問題，后來出現了 Cookie。不過這樣說可能會讓你產生一些誤解，首先無狀態並不是不好，有優點，但也會導致一些問題。而 Cookie 的存在也不是為了解決通訊協議無狀態的問題，只是為了解決客戶端與服務端會話狀態的問題，這個狀態是指后端服務的狀態而非通訊協議的狀態。
SameSite 可以有下面三種值：
- Strict 僅允許一方請求攜帶 Cookie，即瀏覽器將只發送相同站點請求的 Cookie，即當前網頁 URL 與請求目標 URL 完全一致。
- Lax 允許部分第三方請求攜帶 Cookie
- None 無論是否跨站都會發送 Cookie
之前默認是 None 的，Chrome80 后默認是 Lax。
跨域和跨站
首先要理解的一點就是跨站和跨域是不同的。同站(same-site)/跨站(cross-site)」和第一方(first-party)/第三方(third-party)是等價的。但是與瀏覽器同源策略（SOP）中的「同源(same-origin)/跨域(cross-origin)」是完全不同的概念。
同源策略的同源是指兩個 URL 的協議/主機名/端口一致。例如，https://www.taobao.com/pages/...，它的協議是 https，主機名是 www.taobao.com，端口是 443。
同源策略作為瀏覽器的安全基石，其「同源」判斷是比較嚴格的，相對而言，Cookie中的「同站」判斷就比較寬松：只要兩個 URL 的 eTLD+1 相同即可，不需要考慮協議和端口。其中，eTLD 表示有效頂級域名，注冊於 Mozilla 維護的公共后綴列表（Public Suffix List）中，例如，.com、.http://co.uk、.http://github.io 等。eTLD+1 則表示，有效頂級域名+二級域名，例如 taobao.com 等。
舉幾個例子，www.taobao.com 和 www.baidu.com 是跨站，www.a.taobao.com 和 www.b.taobao.com 是同站，a.github.io 和 b.github.io 是跨站(注意是跨站)。
解決辦法：
1.內嵌頁面最好采用同站(SameSite)策略。
2.接口請求參數直接帶上token請求。
3.設置sameSite: ‘none’，( 需https協議，且不同瀏覽器版本有兼容性問題，需要 UA 檢測）
google設置解決方法：
前往 chrome://flags，通過禁用“SameSite by default cookies”功能開關，修改后點擊Relaunch重新啟動即可。如下圖所示：
