前端緩存數據在什麼地方

① 前端數據存儲方式有哪些

為你總結了四種數據存儲方式，希望可以幫到你：

1、Cookie

cookie 用於存儲web頁面的用戶信息。

cookie 是一些數據，存儲在你電腦上的文本文件中。當web伺服器向瀏覽器發送web頁面時，在連接關閉後，服務端不會記錄用戶的信息。Cookie的作用就是用於解決如何記錄客戶端的用戶信息。

2、localStorage

• 允許在瀏覽器中存儲key/value對的數據。

• 用於長期保存整個網站的數據，保存的數據沒有過期時間，直到手動去刪除。

• 屬性是只讀的。

如果你想瀏覽器窗口關閉後還保留數據，可以使用localStorage；如果你只想將數據保存在當前會話中，可以使用sessionStorage.

3、sessionStorage

• 允許在瀏覽器中存儲key/value對的數據。

• 數據對象臨時保存同一窗口（或標簽頁）的數據，在關閉窗口或標簽頁之後也將刪除這些數據。

4、indexedDB

索引資料庫（indexDB）API（作為HTML5 的一部分）對創建具有吩咐本地存儲數據的數據密集型的離線HTML5 Web 應用程序很有用。

同時它還有助於本地緩存數據，使傳統再現Web應用程序（比如移動 Web 應用程序）能夠更快的運行和響應。

想要了解或者學習更多前端知識，推薦北京尚學堂，雄厚的師資力量帶給你高效的學習體驗。

② 說一下前端數據存儲方式（cookies，localstorage，sessionstorage，indexedDB）的區別

Cookie最初是在客戶端用於存儲會話信息的，其要求伺服器對任意HTTP請求發送Set-CookieHTTP頭作為響應的一部分。cookie
以name為名稱，以value為值，名和值在傳送時都必須是URL編碼的。瀏覽器會存儲這樣的會話信息，在這之後，通過為每個請求添加Cookie
HTTP頭將信息發送回伺服器。

localstorage

存儲方式：

以鍵值對(Key-Value)的方式存儲，永久存儲，永不失效，除非手動刪除。

sessionstorage

HTML5 的本地存儲 API 中的 localStorage 與 sessionStorage 在使用方法上是相同的，區別在於 sessionStorage 在關閉頁面後即被清空，而 localStorage 則會一直保存。

IndexedDB

索引資料庫(IndexedDB) API（作為 HTML5 的一部分）對創建具有豐富本地存儲數據的數據密集型的離線 HTML5 Web 應用程序很有用。同時它還有助於本地緩存數據，使傳統在線 Web 應用程序（比如移動 Web 應用程序）能夠更快地運行和響應。

③ ios前端有緩存

ios前端有緩存的解決方法：
1.此時在ios app的沙盒文件中將保存好已經緩存的文件，如果此時沒有退出APP,那麼緩存的內容同時也會保存在內存中；如下圖（此處針對的UIWebView）
2.此時可以看到這Caches文件中，後面的Paul.H5下面多了Cache.db的資料庫，打開資料庫可以看到以下內容；注意 此時的圖片資源也是保存在Paul.H5下面的文件中

④ ☆前端優化：瀏覽器緩存技術介紹

在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在WEB技術體系中扮演非常重要角色，是快速且有效地提升性能的手段。

一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷。

所以，緩存技術是無數WEB開發從業人員在工作過程中不可避免的一大問題。 在產品開發的時候我們總是想辦法避免緩存產生，而在產品發布之時又在想策略管理緩存提升網頁的訪問速度 。了解瀏覽器的緩存命中原理，是開發WEB應用的基礎，本文著眼於此，學習瀏覽器緩存的相關知識，總結緩存避免和緩存管理的方法，結合具體的場景說明緩存的相關問題。希望能對有需要的人有所幫助。

在實際WEB開發過程中，緩存技術會涉及到不同層、不同端，比如：用戶層、系統層、代理層、前端、後端、服務端等， 每一層的緩存目標都是一致的，就是盡快返回請求數據、減少延遲 ，但每層使用的技術實現是各有不同，面對不同層、不同端的優劣，選用不同的技術來提升系統響應效率。所以，我們首先看下各層的緩存都有哪些技術，都緩存哪些數據，從整體上，對WEB的緩存技術進行了解，如下圖所示：

本篇文章重點講的就是上面紅色框部分緩存內容。

當瀏覽器請求一個網站的時候，會載入各種各樣的資源，比如：HTML文檔、圖片、CSS和JS等文件。對於一些不經常變的內容，瀏覽器會將他們保存在本地的文件中，下次訪問相同網站的時候，直接載入這些資源，加速訪問。

那麼如何知曉瀏覽器是讀取了緩存還是直接請求伺服器？如下圖網站來做個示例：

第一次打開該網站後，如果再次刷新頁面。會發現瀏覽器載入的眾多資源中，有一部分size有具體數值，然而還有一部分請求，比如圖片、css和js等文件並沒有顯示文件大小，而是顯示了 from dis cache 或者 from memory cache 字樣。這就說明了，該資源直接從本地硬碟或者瀏覽器內存讀取，而並沒有請求伺服器。

瀏覽器啟用緩存至少有兩點顯而易見的好處： （1）減少頁面載入時間；（2）減少伺服器負載；

瀏覽器是否使用緩存、緩存多久，是由伺服器控制的 。准確來說，當瀏覽器請求一個網頁（或者其他資源）時， 伺服器發回的響應的「響應頭」部分的某些欄位指明了有關緩存的關鍵信息 。下面看下，HTTP報文中與緩存相關的首部欄位：

根據上面四種類型的首部欄位不同使用策略， 瀏覽器中緩存可分為強緩存和協商緩存 ：

當瀏覽器對某個資源的請求命中了強緩存時， 返回的HTTP狀態為200 ，在chrome的開發者工具的network裡面 size會顯示為from cache ，比如：京東的首頁里就有很多靜態資源配置了強緩存，用chrome打開幾次，再用f12查看network，可以看到有不少請求就是從緩存中載入的：

Expires是HTTP 1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由伺服器返回，用GMT格式的字元串表示 ，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires頭標簽的文件，就說明瀏覽器對於該文件緩存具有非常大的控制權。

例如，一個文件的Expires值是2020年的1月1日，那麼就代表，在2020年1月1日之前，瀏覽器都可以直接使用該文件的本地緩存文件，而不必去伺服器再次請求該文件，哪怕伺服器文件發生了變化。

所以， Expires是優化中最理想的情況，因為它根本不會產生請求 ，所以後端也就無需考慮查詢快慢。它的緩存原理，如下：

Expires是較老的強緩存管理header， 由於它是伺服器返回的一個絕對時間 ，在伺服器時間與客戶端時間相差較大時，緩存管理容易出現問題， 比如：隨意修改下客戶端時間，就能影響緩存命中的結果 。所以在HTTP 1.1的時候，提出了一個新的header， 就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒為單位，用數值表示 ，如：Cache-Control:max-age=315360000，它的緩存原理是：

Cache-Control描述的是一個相對時間 ，在進行緩存命中的時候， 都是利用客戶端時間進行判斷 ，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。

這兩個header可以只啟用一個，也可以同時啟用， 當response header中，Expires和Cache-Control同時存在時，Cache-Control優先順序高於Expires ：

此外，還可以為 Cache-Control 指定 public 或 private 標記。 如果使用 private，則表示該資源僅僅屬於發出請求的最終用戶，這將禁止中間伺服器（如代理伺服器）緩存此類資源 。對於包含用戶個人信息的文件（如一個包含用戶名的 HTML 文檔），可以設置 private，一方面由於這些緩存對其他用戶來說沒有任何意義，另一方面用戶可能不希望相關文件儲存在不受信任的伺服器上。需要指出的是，private 並不會使得緩存更加安全，它同樣會傳給中間伺服器（如果網站對於傳輸的安全性要求很高，應該使用傳輸層安全措施）。 對於 public，則允許所有伺服器緩存該資源 。通常情況下，對於所有人都可以訪問的資源（例如網站的 logo、圖片、腳本等）， Cache-Control 默認設為 public 是合理的 。

當瀏覽器對某個資源的請求沒有命中強緩存， 就會發一個請求到伺服器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字元串 ，比如你打開京東的首頁，按f12打開開發者工具，再按f5刷新頁面，查看network，可以看到有不少請求就是命中了協商緩存的：

查看單個請求的Response Header， 也能看到304的狀態碼和Not Modified的字元串，只要看到這個就可說明這個資源是命中了協商緩存，然後從客戶端緩存中載入的 ，而不是伺服器最新的資源：

【Last-Modified，If-Modified-Since】的控制緩存的原理，如下 ：

【Last-Modified，If-Modified-Since】都是根據伺服器時間返回的header，一般來說， 在沒有調整伺服器時間和篡改客戶端緩存的情況下，這兩個header配合起來管理協商緩存是非常可靠的，但是有時候也會伺服器上資源其實有變化，但是最後修改時間卻沒有變化的情況 ，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商緩存的可靠性。 所以就有了另外一對header來管理協商緩存，這對header就是【ETag、If-None-Match】 。它們的緩存管理的方式是：

Etag和Last-Modified非常相似，都是用來判斷一個參數，從而決定是否啟用緩存。 但是ETag相對於Last-Modified也有其優勢，可以更加准確的判斷文件內容是否被修改 ，從而在實際操作中實用程度也更高。

協商緩存跟強緩存不一樣，強緩存不發請求到伺服器， 所以有時候資源更新了瀏覽器還不知道，但是協商緩存會發請求到伺服器 ，所以資源是否更新，伺服器肯定知道。大部分web伺服器都默認開啟協商緩存，而且是同時啟用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:

如果沒有協商緩存，每個到伺服器的請求，就都得返回資源內容，這樣伺服器的性能會極差。

【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同時啟用，這是為了處理Last-Modified不可靠的情況。有一種場景需要注意：

比如，京東頁面的資源請求，返回的repsonse header就只有Last-Modified，沒有ETag：

協商緩存需要配合強緩存使用，上面這個截圖中，除了Last-Modified這個header，還有強緩存的相關header， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。

如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：

⑤ js如何獲取緩存

1、創建一個cache.js文件,前端頁面，定義那些數據需要一次性拿到前端緩存，定義一個對象來保存這些數據。

⑥ 瀏覽器緩存css js文件在哪

在瀏覽器的cache里，谷歌開發者工具f12 network里如果status的狀態是304的，那麼就是讀取緩存的。

⑦ 前端緩存介面數據的實現

前端緩存 API 介面數據，前端怎麼知道數據是否變了，該不該取緩存的數據呢。
可以採用 HTTP 協商緩存 ETag 來實現:
在後台每次修改需要緩存的數據時都進行一次 hash（當然也可以使用其他演算法生成唯一標識）

將介面地址與 hash 值存為鍵值對

邏輯大概為：

⑧ 一個網站從前端到後端有哪些可以緩存的地方

頁面、數據都可以緩存

⑨ 前端HTTP緩存

在面試的時候總是遇到緩存相關問題，回答總是停留緩存就是從瀏覽器中獲取，不向伺服器發送請求，回答的不讓面試官滿意，索性抽點時間整理一下前端相關的緩存，希望下次回答的時候能夠多講點。

前端緩存分為 強緩存 和 協商緩存 ，強緩存就是在緩存未失效時，不在請求服務端，協商緩存就是去跟伺服器比較是否需要重新獲取資源 。

強緩存分為兩種， Cache-control 和 Expires ， Expires 是HTTP1.0的東西，它的值是一個格林時間，比如 Expires: Wed, 21 Oct 2015 07:28:00 GMT ，由於伺服器端和瀏覽器端的時間差異問題，瀏覽器比伺服器時間快，會導致緩存失效。 Cache-control 是HTTP1.1時代的新東西，設置的是一個相對時間， Cache-Control:public, max-age=31536000 ，在31536000秒後才緩存才失效， Cache-control 有很多取值。

強緩存在緩存失效內，不會從原始伺服器獲取新的數據，假如在緩存時段內伺服器有資源更新，會導致資源獲取不及時。

協商緩存有兩組報文