① 前端http請求細節——Cache-Control（緩存機制）
請求和響應中的 Cache-Control 指令並不完全相同，具體可以查看 這里 ，包括指令的具體意思，這里不過多贅述。（默認值：private）
瀏覽器的緩存機制是根據 HTTP 報文的緩存標識進行的，瀏覽器第一次向伺服器發起該請求後拿到請求結果，會根據響應報文中 HTTP 頭的緩存標識，決定是否緩存結果。
瀏覽器緩存策略分為兩種：強制緩存和協商緩存。
強制緩存不會向伺服器發送請求，直接從緩存中讀取資源，可以看到請求返回的狀態碼都是200，並且 Size 代表該緩存的位置。
瀏覽器讀取緩存的順序為memory –> disk。
三級緩存原理 (訪問緩存優先順序)：
在瀏覽器中，瀏覽器會在js，字體，圖片等文件解析執行後直接存入內存緩存中，那麼當刷新頁面時只需直接從內存緩存中讀取(from memory cache)；而css文件則會存入硬碟文件中，所以每次渲染頁面都需要從硬碟讀取緩存(from disk cache)。
為什麼CSS會放在硬碟緩存中？
因為CSS文件載入一次就可渲染出來,我們不會頻繁讀取它,所以它不適合緩存到內存中,但是js之類的腳本卻隨時可能會執行,如果腳本在磁碟當中,我們在執行腳本的時候需要從磁碟取到內存中來,這樣IO開銷就很大了,有可能導致瀏覽器失去響應。
若伺服器的資源最後被修改時間 > If-Modified-Since的欄位值
則重新返回資源，狀態碼為200；否則則返回304，代表資源無更新，可繼續使用緩存文件
If-None-Match 的欄位值 = 該資源在伺服器的Etag值
一致則返回304，代表資源無更新，繼續使用緩存文件；不一致則重新返回資源文件，狀態碼為200。
ETag 和 Last-Modified 區別
參考鏈接：
https://juejin.im/entry/5ad86c16f265da505a77dca4
https://www.cnblogs.com/suihang/p/12855345.html
https://www.jianshu.com/p/54cc04190252
② ☆前端優化：瀏覽器緩存技術介紹
在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在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， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。
如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：
③ HTML5的5種存儲方式詳解
引言
本篇文章主要介紹了前端HTML5幾種存儲方式的總結 ，主要包括本地存儲localstorage，本地存儲sessionstorage，離線緩存（application cache），Web SQL，IndexedDB。有興趣的可以了解一下。
正文開始~
h5之前，存儲主要是用cookies。cookies缺點有在請求頭上帶著數據，大小是4k之內。主Domain污染。
主要應用：購物車、客戶登錄
對於IE瀏覽器有UserData，大小是64k,只有IE瀏覽器支持。
目標
存儲方式：
以鍵值對(Key-Value)的方式存儲，永久存儲，永不失效，除非手動刪除。
大小：
每個域名5M
支持情況：
注意：IE9 localStorage不支持本地文件，需要將項目署到伺服器，才可以支持！
常用的API：
getItem //取記錄
setIten//設置記錄
removeItem//移除記錄
key//取key所對應的值
clear//清除記錄
存儲的內容：
數組，圖片，json，樣式，腳本。。。（只要是能序列化成字元串的內容都可以存儲）
HTML5 的本地存儲 API 中的 localStorage 與 sessionStorage 在使用方法上是相同的，區別在於 sessionStorage 在關閉頁面後即被清空，而 localStorage 則會一直保存。
本地緩存應用所需的文件
使用方法：
①配置manifest文件
頁面上：
Manifest 文件：
manifest 文件是簡單的文本文件，它告知瀏覽器被緩存的內容（以及不緩存的內容）。
manifest 文件可分為三個部分：
①CACHE MANIFEST - 在此標題下列出的文件將在首次下載後進行緩存
②NETWORK - 在此標題下列出的文件需要與伺服器的連接，且不會被緩存
③FALLBACK - 在此標題下列出的文件規定當頁面無法訪問時的回退頁面（比如 404 頁面）
完整demo：
伺服器上： manifest文件需要配置正確的MIME-type，即 "text/cache-manifest"。
如Tomcat:
常用API：
核心是applicationCache對象，有個status屬性，表示應用緩存的當前狀態：
0（UNCACHED） : 無緩存， 即沒有與頁面相關的應用緩存
1（IDLE） : 閑置，即應用緩存未得到更新
2 （CHECKING） : 檢查中，即正在下載描述文件並檢查更新
3 （DOWNLOADING） : 下載中，即應用緩存正在下載描述文件中指定的資源
4 （UPDATEREADY） : 更新完成，所有資源都已下載完畢
5 （IDLE） : 廢棄，即應用緩存的描述文件已經不存在了，因此頁面無法再訪問應用緩存
相關的事件：
表示應用緩存狀態的改變：
checking : 在瀏覽器為應用緩存查找更新時觸發
error : 在檢查更新或下載資源期間發送錯誤時觸發
noupdate : 在檢查描述文件發現文件無變化時觸發
downloading : 在開始下載應用緩存資源時觸發
progress：在文件下載應用緩存的過程中持續不斷地下載地觸發
updateready : 在頁面新的應用緩存下載完畢觸發
cached : 在應用緩存完整可用時觸發
Application Cache的三個優勢：
① 離線瀏覽
② 提升頁面載入速度
③ 降低伺服器壓力
注意事項：
1. 瀏覽器對緩存數據的容量限制可能不太一樣（某些瀏覽器設置的限制是每個站點 5MB）
2. 如果manifest文件，或者內部列舉的某一個文件不能正常下載，整個更新過程將視為失敗，瀏覽器繼續全部使用老的緩存
3. 引用manifest的html必須與manifest文件同源，在同一個域下
4. 瀏覽器會自動緩存引用manifest文件的HTML文件，這就導致如果改了HTML內容，也需要更新版本才能做到更新。
6. FALLBACK中的資源必須和manifest文件同源
7. 更新完版本後，必須刷新一次才會啟動新版本（會出現重刷一次頁面的情況），需要添加監聽版本事件。
8. 站點中的其他頁面即使沒有設置manifest屬性，請求的資源如果在緩存中也從緩存中訪問
9. 當manifest文件發生改變時，資源請求本身也會觸發更新
離線緩存與傳統瀏覽器緩存區別：
1. 離線緩存是針對整個應用，瀏覽器緩存是單個文件
2. 離線緩存斷網了還是可以打開頁面，瀏覽器緩存不行
3. 離線緩存可以主動通知瀏覽器更新資源
關系資料庫，通過SQL語句訪問
Web SQL 資料庫 API 並不是 HTML5 規范的一部分，但是它是一個獨立的規范，引入了一組使用 SQL 操作客戶端資料庫的 APIs。
支持情況：
Web SQL 資料庫可以在最新版的 Safari, Chrome 和 Opera 瀏覽器中工作。
核心方法：
①openDatabase： 這個方法使用現有的資料庫或者新建的資料庫創建一個資料庫對象。
②transaction： 這個方法讓我們能夠控制一個事務，以及基於這種情況執行提交或者回滾。
③executeSql： 這個方法用於執行實際的 SQL 查詢。
打開資料庫：
執行查詢操作：
插入數據：
讀取數據：
由這些操作可以看出，基本上都是用SQL語句進行資料庫的相關操作，如果你會MySQL的話，這個應該比較容易用。
索引資料庫 (IndexedDB) API（作為 HTML5 的一部分）對創建具有豐富本地存儲數據的數據密集型的離線 HTML5 Web 應用程序很有用。同時它還有助於本地緩存數據，使傳統在線 Web 應用程序（比如移動 Web 應用程序）能夠更快地運行和響應。
非同步API：
在IndexedDB大部分操作並不是我們常用的調用方法，返回結果的模式，而是請求——響應的模式，比如打開資料庫的操作
這樣，我們打開資料庫的時候，實質上返回了一個DB對象，而這個對象就在result中。由上圖可以看出，除了result之外。還有幾個重要的屬性就是onerror、onsuccess、onupgradeneeded（我們請求打開的資料庫的版本號和已經存在的資料庫版本號不一致的時候調用）。這就類似於我們的ajax請求那樣。我們發起了這個請求之後並不能確定它什麼時候才請求成功，所以需要在回調中處理一些邏輯。
關閉與刪除：
數據存儲：
indexedDB中沒有表的概念，而是objectStore，一個資料庫中可以包含多個objectStore，objectStore是一個靈活的數據結構，可以存放多種類型數據。也就是說一個objectStore相當於一張表，裡面存儲的每條數據和一個鍵相關聯。
我們可以使用每條記錄中的某個指定欄位作為鍵值（keyPath），也可以使用自動生成的遞增數字作為鍵值（keyGenerator），也可以不指定。選擇鍵的類型不同，objectStore可以存儲的數據結構也有差異。
學習從來不是一個人的事情，要有個相互監督的夥伴，想要學習或交流前端問題的小夥伴可以私信「學習」小明獲取web前端入門資料，一起學習，一起成長！
④ 前端緩存的理解 或者 前端數據持久化的理解(強制緩存、協商緩存)
緩存可以說是性能優化中簡單高效的一種優化方式了。一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，並且由於 緩存文件可以重復利用 ，還可以減少帶寬，降低網路負荷。
對於一個數據請求來說，可以分為發起 網路請求、後端處理、瀏覽器響應 三個步驟。瀏覽器緩存可以幫助我們在第一和第三步驟中優化性能。比如說直接使用緩存而不發起請求，或者發起了請求但後端存儲的數據和前端一致，那麼就沒有必要再將數據回傳回來，這樣就減少了響應數據。
①不存在該緩存結果和緩存標識，強制緩存失效，則直接向伺服器發起請求
②存在該緩存結果和緩存標識，但該結果已失效，強制緩存失效，則使用協商緩存
③存在該緩存結果和緩存標識，且該結果尚未失效，強制緩存生效，直接返回該結果
控制強制緩存的欄位分別是Expires和Cache-Control，其中Cache-Control優先順序比Expires高。
Cache-Control、Expires都是緩存到期時間，Cache-Control是相對值，Expires是絕對值，即再次發送請求時，如果時間沒到期，強制緩存生效。
註：在無法確定客戶端的時間是否與服務端的時間同步的情況下，Cache-Control相比於expires是更好的選擇，所以同時存在時，只有Cache-Control生效。
①協商緩存生效，返回304
②協商緩存失效，返回200和請求結果
這里我們以博客的請求為例，狀態碼為灰色的請求則代表使用了強制緩存，請求對應的Size值則代表該緩存存放的位置，分別為from memory cache 和 from disk cache。那麼from memory cache 和 from disk cache又分別代表的是什麼呢？什麼時候會使用from disk cache，什麼時候會使用from memory cache呢？
from memory cache代表使用 內存中的緩存 ，from disk cache則代表使用的是 硬碟中的緩存 ，
⑤ 前端瀏覽器緩存機制
在前端開發中，性能是一個永恆的話題，沒有最好，只有更好。判斷一個網站性能好壞，一個直入眼觀的即是網頁的反應速度，有一個方式就是使用緩存，一個優秀的緩存策略可以縮短網頁請求的時間，減少延遲，並且網頁可以重復利用，還可以減少帶寬，降低網路負荷。
1： 為什麼需要緩存？
a：緩存可以減少用戶等待時間，提升用戶體驗
b：減少網路帶寬消耗
c：降低伺服器壓力
Note：緩存使用不當，也會造成『臟數據』問題
2：常見的緩存類型
強緩存 -
Expires伺服器端設置，表示該資源的過期時間，會有弊端，客戶端時間和伺服器時間不一致的問題。
Cache-Control：max-age表示緩存資源的最大生命周期，單位是秒
所以Expires 結合 Cache-Control 一起使用，大型網站中一般比較適用
協商緩存-
Last-Modified：值為資源的最後更新時間，隨伺服器response返回
If-Modified-Since：通過比較兩個時間來判斷資源在兩次請求期間是否有過修改，如果沒有，則命中協商緩存
Etag：表示資源內容的唯一標識，即資源的消息摘要
If-None-Match：伺服器通過比較請求頭中的If-None-Match與當前資源的Etag是否一致來判斷資源是否在兩次請求期間有過修改
3：緩存流程圖示：
a：瀏覽器會先檢測強緩存類型（Cache-Control 或者 Expires）是否有效；命中直接瀏覽器本地獲取緩存資源
b：未命中。伺服器會根據請求頭Request Header驗證這個資源是否命中協商緩存，稱之為HTTP二次驗證，命中，伺服器返回請求，但返回資源，而是告訴客戶端直接中直接從瀏覽器緩存中獲取
Note：
1.強緩存不會發生請求，協商緩存存在伺服器請求
2.當協商緩存也未命中時，則伺服器會將資源發送到客戶端
3.F5刷新頁面，會跳過強緩存
4.Ctrl+F5刷新頁面，跳過強緩存和協商緩存
5.不會緩存的情況
HTTPS POST請求 根據Cookie獲取認證信息 Request Header Cache-Control：no-cache， max-age=0
6.小故事大道理
上文對整個概念做了闡述，還是不夠形象，我們來通過幾個小故事生動理解一下：
故事一：Last-Modified
瀏覽器：Hi，我需要 jartto.min.js 這個文件，如果是在 Last-Modified: Fri Feb 15 2019 19:57:31 GMT 之後修改過的，請發給我。
伺服器：（檢查文件的修改時間）
伺服器：Oh，這個文件在那個時間之後沒有被修改過，你已經有最新的版本了。
瀏覽器：太好了，那我就顯示給用戶了。
故事二：ETag
瀏覽器：Hi，我需要 jartto.css 這個文件，有沒有不匹配 3c61f-1c1-2aecb436 這個串的
伺服器：（檢查 ETag…）
伺服器：Hey，我這里的版本也是 3c61f-1c1-2aecb436，你已經是最新的版本了
瀏覽器：好，那就可以使用本地緩存了
⑥ cpu的緩存分為幾級
cpu的緩存分為三級。
一級緩存（L1）、二級緩存（L2）和三級緩存（L3）。我們現在常見的是三級緩存。但是CPU在實際數據讀取中重要的卻是一級緩存，因為一級緩存速度最快，二級緩存其次，三級緩存最慢，只是三級緩存的容量最大，上百MB的都有，更容易體現產品更新換代時的價值。
cpu
CPU是Central Processing Unit（中央處理器）的縮寫，CPU的詳細參數包括內核結構，主頻，外頻，倍頻，介面，緩存，多媒體指令集，製造工藝，電壓，封裝形式，整數單元和浮點單元等。CPU一般由邏輯運算單元、控制單元和存儲單元組成。
在邏輯運算和控制單元中包括一些寄存器，這些寄存器用於CPU在處理數據過程中數據的暫時保存。一般在市面上購買CPU時所看到的參數一般是以（主頻前端匯流排二級緩存）為格式的。
例如Intel P6670的就是（2.16GHz800MHz2MB）。CPU的性能指標包括主頻、倍頻、外頻、匯流排頻率、二級緩存、工作電壓、介面和製造工藝等。
⑦ wen前端緩存技術都有哪些
wen ? 是web吧
大體知道一個，分布式緩存技術 這個是緩存在內存里
還有網站靜態化也是一種緩存，緩存在物理盤上