閱讀本文，你將:
學習 回應頭 很重要嗎？
真的很重要。
不信你看看下面的場景，眼熟不？
一、預覽、下載讓人操碎了心?
#1.1 場景
##我不只一次聽到同事、群友們討論這個問題：
「後端提供了一個txt#(或pdf/'json' 等)檔案的下載url，可以當我用a 標籤打開時，卻變成了預覽…怎麼辦？救！！！」
此時，就會有人上去推薦
FileSaver.js 或「手寫讀流另存為」。
然後還有人附和...
我：？ ？ ？
這是需要寫程式碼才能解決的問題嗎？
如果你有了解過
Content-Disposition 這個 Response Header，那你一定知道，只需要回應頭上增加一行，問題就能迎刃而解。
1.2 介紹
Content-Disposition
它支援三種格式的值：
Content-Disposition: inline
Content-Disposition: attachment
url 格式有關。
Content-Disposition: attachment; filename="filename.jpg"
註：如果需要預覽，需要配合適當的Content-Type 食用；
##1.3 範例
為此，我特意寫了一個
express
小範例。
express
應用程式下寫了三個路由，如下：<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">const user = {
name: "摸鱼的春哥",
blogUrl: "https://juejin.cn/user/1714893870865303"
}
const contentDispositionInline = async (req, res, next) => {
res.setHeader('Content-Disposition', 'inline')
res.send(user)
}
const contentDispositionFilename = async (req, res, next) => {
res.setHeader('Content-Disposition', 'attachment; filename="chunge.json"')
res.send(user)
}
const contentDispositionNoFilename = async (req, res, next) => {
res.setHeader('Content-Disposition', 'attachment')
res.send(user)
}</pre><div class="contentsignin">登入後複製</div></div>然後我分別存取三個路由，效果差異：
二、專案升級了，需要客戶清空快取？
2.1 場景
實作：「客戶回饋
Bug
還是沒修復。」你：「哥，真修復了，要不要讓客戶清一下快取？」實作：「啊？客戶說他不會清除…」
…
永遠不要期望你的客戶會進行
「那些研發才懂」
的操作。也不要把你的問題，歸因到 瀏覽器快取 上。
瀏覽器快取
是被發明出來優化使用者體驗的，並不是發明出來阻礙使用者的。 因此，理解如何使用
Cache-Control
這個回應頭，是前端的必知技能。
2.2 介紹
Cache-Control：用來指定快取機制。 緩存，作為前端八股文必考知識，相信大家已經耳熟能詳。
常見的
Cache-Control 屬性如下：
| Response Header屬性 |
值 |
#意思 |
| cache-control |
no-store |
不緩存，這會讓客戶端、伺服器都不緩存，也就沒有所謂的強緩存、協商緩存了。 |
| cache-control |
public |
表示回應可以被任何物件（包括：發送請求的客戶端，代理伺服器，等等）緩存，即使是通常不可緩存的內容。 （例如：1.該回應沒有max-age指令或Expires訊息標頭；2. 此回應對應的請求方法是POST。） |
| cache-control |
# private |
表示回應只能被單一使用者緩存，不能作為共享快取（即代理伺服器不能快取它）。私有快取可以快取回應內容，例如：對應使用者的本機瀏覽器。 |
| cache-control |
max-age= |
設定快取儲存的最大週期，超過這個時間快取被認為過期(單位秒)。與Expires相反，時間是相對於請求的時間。 |
- 不快取
不快取是最容易理解，每個請求都會從服務端重新獲取，不進行任何快取。
此策略只需要賦予 Cache-Control: no-store 回應頭即可。
- 強快取
有些資源文件，幾乎不會改變（例如已經hash化命名的文件），則可以直接從本地快取獲取，這就是所謂的強緩存 ;
透過cache-control: public/private 或cache-control: max-age= 都可以指定機制為強緩存。
- 協商快取
這是一種更為複雜快取機制，無法再透過回應頭 簡單粗暴地 指定實現，而是需要前後端協作配合。
簡單來說，每次請求資源前前端會寫代前一次的回應hash，問詢服務端資源是否發生過變化，從而達到準確快取的效果。
本文不贅述，如果有興趣，可以參考此文：juejin.cn/post/703078…
##2.3 實際生產如何運用？
凡是名稱帶有 - hash
值的資源，一律可以強快取。 （畢竟內容一旦有變化，名稱的
hash 也跟著變了）
凡是透過- cdn
引入的第三方函式庫，均建議攜帶版本信息，這樣也可以強緩存。 （例如
/xx/xx/jquery.min.js 切換為jquery@3.6.0/dist/jquery.min.js）
#凡是- html
、ico 這類命名固定的文件，建議一律不快取 或協商快取。
三、我的 Cookie 不可能這麼可愛！
3.1 場景
"春哥春哥，為啥我登入成功了，請求還是401 ？"
"春哥春哥，為啥我存進cookie 的值取不到？"
"春哥春哥，這破cookie 是不是壞了，瀏覽器裡看明明有值，為啥我訪問不了？"
我：「兄弟，你有了解過一個叫set-cookie 的回應頭嗎？」
是它！是它！就是它！關於cookie 的各種異常，全靠它!
3.2 介紹
Cookie 曾經是Web 開發無法繞開的一道門檻，而現在它的存在感越來越弱，但海量的存量項目並不會因為技術的趨勢而消失，它們依然很有價值，依然需要維護。
而 set-cookie 回應頭正是 Cookie 系統中最為核心的 第一主角。
Set-Cookie，並且限定Cookie 的各種特性。
這些特性就包含：
- 過期時限；
Expires=<date></date>
- 存活週期；
Max-Age=<number></number>
#在cookie 失效之前需要經過的秒數。 0 或 -1 直接失效；此屬性的優先權高於 Expires。
- 網域；
Domain=<domain-value></domain-value>
指定cookie 只能在什麼網域下產生；（允許通配，這個屬性主要出於安全性）
- 路徑;
Path=<path-value></path-value>
比Domain 更為細緻的控制策略，甚至指定了 xx 路徑下才能傳送Cookie。
- 只在
Https 產生；Secure
如果set-cookie 頭中有Secure 屬性，那麼瀏覽器只會在Https 環境產生和發送Cookie。
- 禁用
js 操作API；HttpOnly
如果set-cookie 頭中有HttpOnly 屬性，那麼Cookie 屬性的產生、讀寫、發送就只能由瀏覽器透過"回應頭" 控制了，不在允許前端透過js 動作 Cookie。
- 是否允許跨域攜帶；
SameSite=<samesite-value></samesite-value>
支援屬性包括Strict、Lax、None，分別表示：
-
Strict: 完全不能跨域攜帶；
-
Lax: 只允許從外站導航到來源站時攜帶Cookie
-
None：跨域也行，不限制。
3.3 開發常見問題分析
-
#你已經登入成功了，請求還是 401？
早期非常多的項目，使用Cookie 作為使用者身分識別的手段，例如Spring MVC 項目就是透過給Cookie 一個JSeesionId 的值作為識別，判斷你是否出於當前會話。
而 "登入了，卻還 401" 這個現象，如果服務端沒有問題的話，多半是 瀏覽器其實並未儲存Cookie。
換個說法，你每次發起請求，服務端都認為你是一次 新的會話，和上一次 登入的你 並非同一人。
如果你正處於 http 環境，那你可能需要暫時移除 Secure 屬性。
存不進、取不出？
先確認是否有域的限制、是否有路徑的限制、是否有HttpOnly?
逐一檢查下來，問題不難解決。
（學習影片分享：web前端）
以上是【整理總結】前端必知必會的幾個實用響應頭的詳細內容。更多資訊請關注PHP中文網其他相關文章！
