覽器緩存對于前端一點都不陌生，最常見的就是，新版本上線了，測試卻說這怎么還沒有變化呢？使用 ctr + F5 強制刷新之后，立馬就好了。或者清除瀏覽器緩存，按住ctr+shift+delete，彈出如圖：

我們會發(fā)現目前瀏覽器緩存的圖片和文件的大小。或者進入chrome://chrome-urls/找到chrome://cache/ 就可以看到所有緩存的地址列表。對于瀏覽器緩存，前端對它是又愛又恨，有時想保留，有時想禁掉，所以看看瀏覽器緩存到底是怎樣的？

一、什么是瀏覽器緩存？

瀏覽器緩存就是瀏覽器根據 url 第一次訪問網站之后，將網站的 html、css、js、圖片等文件復制一份保留到瀏覽器中，當你二次訪問這個 url 的網站時，如果網站沒有明確表示有更新時，瀏覽器直接在緩存中查找內容，不會再次請求網頁內容，只有網頁明確表示有更新時，瀏覽器才會向服務器發(fā)起網路請求，再次下載網頁。

如上圖，百度首頁就是使用了緩存機制，首次訪問之后 web資源被緩存，在后面重復請求中，資源直接在緩存中讀取，而不是向服務器請求資源。

二、為什么使用緩存？

2.1、為什么很多網站二次打開速度很快？

網頁二次打開很快，主要原因是第一次加載頁面過程中，緩存了部分耗時數據，這一現象，對于單頁面應用開發(fā)非常明顯。

上一篇文章《瀏覽器工作原理》中，瀏覽器工作流程介紹，輸入網址回車以后瀏覽器向服務器發(fā)起服務之前，會現在瀏覽器緩存中查詢是否有需要的文件？如果有則直接在緩存中獲取文件，避免向服務器請求和下載文件，所以節(jié)省了一部分時間。

2.2、瀏覽器緩存優(yōu)點

1、減少網絡帶寬消耗

對于網站運營者或者訪問網頁的用戶，帶寬就代表著 money ，過多的消耗帶寬，我們服務器配置就得升級，使用瀏覽器緩存之后，就會減少網絡流量，降低運營成本。

2、降低服務器壓力

使用瀏覽器緩存之后，除第一次訪問需要向服務器請求網站全部資源，后續(xù)訪問可以重復使用瀏覽器本地緩存，減少對服務器的請求，間接降低服務器的壓力，同時，搜索引擎的爬蟲也會根據緩存過期機制降低抓取的頻率，也可以降低服務器壓力。

3、減少網絡延遲，加快網頁加載

瀏覽器緩存 web資源后，減少網絡請求，可以更快速地獲取到服務器返回數據，同時使用瀏覽器緩存內的文件比服務器獲取快很多，所以網頁加載速度明顯快很多。

三、瀏覽器的緩存規(guī)則

對于瀏覽器端的緩存來講，這些規(guī)則是在 http 協議和 meta 標簽中定義的。分別從兩個維度：新鮮度和校驗值，規(guī)定瀏覽器是否可以直接使用緩存中的副本，還是直接從服務器獲取最新資源。

3.1、新鮮度(過期)：瀏覽器緩存的有效期，緩存必須滿足以下兩個條件，瀏覽器才會認為是最新的，可以直接使用。

• 含有完整的過期時間控制頭信息，并在有效期內。
• 瀏覽器已經使用過這個副本，并且在會話中已經檢查過新鮮度。

3.2、校驗值(驗證)：服務器返回資源的時候，會在響應頭信息中帶上資源實體標簽 Entity Tag，可以用來作為瀏覽器再次請求過程的校驗標識，如果發(fā)現校驗標識不匹配，說明資源已經被修改過或過期，瀏覽器需要重新請求資源。

四、如何控制緩存？

緩存規(guī)則可以設置在html的meta標簽，也可以設置在http協議頭內。

4.1、前端 html 中 meta 標簽

在 html 頁面中加入緩存設置，代碼如下：

<meta http-equiv="Pragma" content="no-cache"  />
<!-- Pragma是http1.0版本中給客戶端設定緩存方式之一 -->

上邊代碼，禁止瀏覽器緩存，瀏覽器每次訪問網頁都要去服務器請求。事實這種禁用緩存形式作用有限：

• 只有IE瀏覽器才能標識這段 meta 的含義，其他主流瀏覽器僅認識 “Cache-Control:no-store” 的 meta 標簽。
• 在IE瀏覽器中，并不一定添加 pragma，但是會讓當前網頁每次都會向服務器發(fā)送請求。

4.2、HTTP協議頭

http請求和響應頭中，與緩存相關的常見類型：

各種類型之間的關系和區(qū)別：

• Cache-Control 與 Expires：它兩作用一樣，都表明當前資源的有效期，控制瀏覽器是取緩存還是直接向服務器獲取，Cache-Control可以設置的更細致，如果同時設置，它的優(yōu)先級高于Expires。
• Last-Modified / ETag 與 Cache-Control / Expires：配置Last-Modified/ETag的情況下，瀏覽器再次訪問URL的資源，還是會發(fā)送請求到服務器，詢問文件是否已經修改，如果沒有，服務器會給瀏覽器返回304，瀏覽器直接從本地緩存中取就好了，反之，服務器會直接向瀏覽器返回數據。Cache-Control / Expires 檢測本地緩存是否還在有效期內，在有效期內，直接使用本地緩存，阻止發(fā)送請求。如果同時設置，Cache-Control / Expiress 優(yōu)先級更高。一般情況下，兩者配合使用，因為即使服務器設置緩存時間, 當用戶點擊“刷新”按鈕時，瀏覽器會忽略緩存繼續(xù)向服務器發(fā)送請求，這時Last-Modified/ETag將能夠很好利用304，從而減少響應開銷。
• Last-Modified 與 ETag：ETag主要是為了解決Last-Modified比較難解決的問題：1、Last-Modified標注的最后修改只能精確到秒級，如果某些文件在1秒鐘以內，被修改多次的話，它將不能準確標注文件的新鮮度。2、如果某些文件會被定期生成，當有時內容并沒有任何變化，但Last-Modified卻改變了，導致文件沒法使用緩存。3、有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形。ETag是服務器自動生成或開發(fā)者生成對應資源在服務器的唯一標識符，能夠更加精準控制緩存。兩者可以一起使用，服務器優(yōu)先驗證ETag，一致時，才會繼續(xù)比對Last-Mofifed，才決定是否要返回304。

五、不能緩存的請求

并不是所有的請求都能被緩存，無法被緩存的有：

• post 請求無法被緩存。
• 需要根據cookie、認證信息等決定輸入內容的動態(tài)請求不能被緩存。
• http響應頭中不包含Last-Modified/ETag，也不包含Cache-Control/Expiress的請求無法被緩存。
• http信息頭明確設置Cache-Control:no-cache,pragma:no-cache或Cache-Control:max-age=0瀏覽器不緩存時。

存是個老生長談的問題，對于前端工程師來講更是我們的必修課?；蛟S很多人會說我的項目并沒有問題，根本不需要聊什么緩存。如果真的是這樣，只能證明你前端道路才剛剛開始。

背景

小郭今天分享緩存的原因在于：公司的一個核心APP中嵌入了SPA，而且應用核心都分布在SPA中，功能復雜且重。問題出現了：應用核心頁面打開一直處于加載狀態(tài)，排除掉弱網環(huán)境的原因，重點就在于沒有緩存，每次進入頁面都需要重載DOM和數據，拖慢頁面打開速度。

那應該處理緩存問題呢？接下來小郭從三個方向來講解。

瀏覽器緩存策略

在了解瀏覽器緩存前，我們需要先了解一下相關的概念：cache-control，expires，last-Modified，ETag。

瀏覽器通過請求頭實現緩存，關鍵的請求頭有cache-control，expires，last-Modified，ETag等。我們從時間和空間兩個角度來看瀏覽器緩存。

時間

瀏覽器發(fā)送第一次請求：不緩存，服務端根據設定的緩存策略返回相應的header，如：cache-control，expires，last-Modified，ETag。

瀏覽器發(fā)送第二次請求：

• 強緩存策略：不需要和服務端通信就決定是否使用緩存，cache-control優(yōu)先級大于expires① 有cache-control且不過期，返回本地磁盤緩存，狀態(tài)值200；② 有expires且不過期，返回本地磁盤緩存，狀態(tài)值200。
• 協商緩存策略：需要和服務端通信決定是否用緩存，Etag優(yōu)先級大于last-Modified。① 有Etag，請求頭添加If-None-Match，值就是上次返回的Etag值，然后發(fā)送給服務端。服務端對比If-None-Match與現有的Etag值是否一樣；一樣的話只返回header，狀態(tài)碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態(tài)碼200；② 有l(wèi)ast-Modified，添加請求頭If-Modified-Since，值是上次返回的last-Modified，然后發(fā)送給服務端。服務端對比If-Modified-Since與現有的是否一樣；一樣的話返回只返回header，狀態(tài)碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態(tài)碼200
• 無緩存

空間

• 瀏覽器和服務端：服務端需要決定使用哪種緩存策略并在響應頭返回；前端不需要設置，是瀏覽器本身機制。
• html和靜態(tài)資源：通常html不設置緩存，因為其它資源的入口都是html文件；靜態(tài)資源（js，css，圖片等）會設置緩存

部署時緩存的問題

如果緩存就按理論上設置，那就太簡單了。在實際應用有個嚴重的問題，我們不僅要緩存代碼，還需要更新代碼。如果靜態(tài)資源名字不變，怎么讓瀏覽器即能緩存又能在有新代碼時更新。最簡單的解決方式就是靜態(tài)資源路徑添加一個版本值，版本不變就走緩存策略，版本變了就加載新資源。如下：

<script src="xx/xx.js?v=24334452"></script>

然而這種處理方式在部署時有問題。

解決方法：靜態(tài)資源和頁面是分開部署

• 先部署頁面再部署靜態(tài)資源，會出現用戶訪問到舊的資源
• 先部署靜態(tài)資源再部署頁面，會出現沒有緩存用戶加載到新資源而報錯

這些問題的本質是以上的部署方式是“覆蓋式發(fā)布”，解決方式是“非覆蓋式發(fā)布”。即用靜態(tài)資源的文件摘要信息給文件命名，這樣每次更新資源不會覆蓋原來的資源，先將資源發(fā)布上去。這時候存在兩種資源，用戶用舊頁面訪問舊資源，然后再更新頁面，用戶變成新頁面訪問新資源，就能做到無縫切換。簡單來說就是給靜態(tài)文件名加hash值。

那如何實現呢？

現在前端代碼都用webpack之類的構建工具打包，那么結合webpack該怎么做，怎么才能做到持久化緩存？

webpack持久化緩存

一、webpack給文件名添加hash值是很簡單的，但hash/chunkhash/contenthash要用哪個呢？

官方定義

hash: unique hash generated for every build

chunkhash: hashes based on each chunks' content

contenthash: hashes generated for extracted content

根據分析，contenthash才是我們需要的，內容有更新，hash值才會更新。

二、webpack會打包業(yè)務代碼、第三方庫及運行時代碼，為保證緩存互不干擾，應該將它們提取出來。

第三方庫提取方式是設置optimization的splitChunks的cacheGroups。splitChunks能提取模塊，cacheGroups能緩存模塊，并且cacheGroups的配置會覆蓋splitChunks相同配置，既能提取又能緩存，故只需設置cacheGroups。

運行時代碼的提取方式為配置runtimeChunk，默認為false，表示運行時代碼嵌入到不同的chunk文件中；現在將運行時代碼提取出來，并命名為manifest。

module.exports = {
  entry: {
    index: "./src/index.js",
    bar: "./src/bar.js"
  },
  output: {
    filename: "[name].[contenthash].js"
  },
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test:/[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all"
        }
      }
    },
    runtimeChunk: {
      name: "manifest"
    }
  }
};

三、 moduleName 和 chunkName 對文件的影響

module：就是js模塊

chunk：webpack編譯過程中由多個module組成的文件

bundle：bundle是chunk文件的最終狀態(tài)，是webpack編譯后的結果

一個文件被分離為3個文件，文件間怎么相互依賴的，會影響彼此打包，解決方法是將moduleId和chunkId改成按照文件路徑生成。

optimization: {
  moduleIds: 'hashed',
  namedModules: true,
  namedChunks: true
}

這樣子moduleId在編譯后的文件是文件目錄的hash值，更加安全。這也是namedChunks在production默認為false的原因，不想依賴的文件路徑在編譯后的文件直接展示，但是為了持久性緩存，這里也只能打開。

四、CSS文件緩存

當css代碼提取成單獨文件，當我們改變css時，怎么保證不影響引用它的js文件呢？配置如下：

plugins: [
  new MiniCssExtractPlugin({
    filename: "[contenthash].css"
  })
]

webpack持久化緩存目標是當且僅當該文件內容變動才改變該文件名字的hash值

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = { 
  output: { 
    filename: [name].[contenthash].js, // 讓hash值只在內容變動時更新 
    chunkFilename: [name].[contenthash].js // 動態(tài)引入的模塊命名，同上 
  }, 
  module: { 
    rules: [ { 
      test: /\.css$/, 
      use: [ 
        "loader: MiniCssExtractPlugin.loader", // 提取出來css "css-loader" 
      ] 
    } ] 
  }, 
  optimization: { 
    moduleIds: "hashed", // 混淆文件路徑名 
    runtimeChunk: { name: 'manifest' }, // 提取runtime代碼命名為manifest 
    namedModules: true, // 讓模塊id根據路徑設置，避免每增加新模塊，所有id都改變，造成緩存失效的情況 
    namedChunks: true, // 避免增加entrypoint，其他文件都緩存失效 
    cacheGroups: { 
      vendor: { // 提取第三方庫文件 
        test: /[\\/]node_modules[\\/]/, 
        name: 'vendors', chunks: 'all', 
      }, 
    },
  } 
  plugins: [ 
    new webpack.HashedModuleIdsPlugin(), // 與namedModules: true作用一樣 
    new MiniCssExtractPlugin({ 
      filename: "[contenthash].css", // css文件也是按contenthash命名 
      chunkFilename: "[contenthash].css", // 動態(tài)引入的css命名，同上 
    }) 
  ], 
}

總結

瀏覽器有其緩存機制，想要既能緩存又能在部署時沒有問題，需要給靜態(tài)文件名添加hash值。在webpack中，有些配置能讓我們實現持久化緩存。感興趣的同學可以自行去測試哦！

有任何問題可以在下方留言，想了解更多前端知識歡迎關注公眾號“一郭鮮”，文章也將同步于公眾號，前端學習不迷路

一、是什么
函數緩存，就是將函數運算過的結果進行緩存

本質上就是用空間（緩存存儲）換時間（計算過程）

常用于緩存數據計算結果和緩存對象

二、如何實現
實現函數緩存主要依靠閉包、柯里化、高階函數，這里再簡單復習下

1-閉包  
	- 閉包可以理解成，函數 + 函數體內可訪問的變量總和
	- add函數本身，以及其內部可訪問的變量，即 a = 1，這兩個組合在?起就形成了閉包
  
    (function() {
        var a = 1;
        function add() {
            const b = 2
            let sum = b + a
            console.log(sum); // 3
        }
        add()
      })()
2-柯里化    
	- 將一個二元函數拆分成兩個一元函數
	// 非函數柯里化
    var add = function (x,y) {
        return x+y;
    }
    add(3,4) //7

    // 函數柯里化
    var add2 = function (x) {
        //**返回函數**
        return function (y) {
            return x+y;
        }
    }
    add2(3)(4) //7

3-高階函數
  - 通過接收其他函數作為參數或返回其他函數的函數
    function foo(){
      var a = 2;

      function bar() {
        console.log(a);
      }
      return bar;
    }
    var baz = foo();
    baz();//2
	- 函數 foo 如何返回另一個函數 bar，baz 現在持有對 foo 中定義的bar 函數的引用。由于閉包特性，a的值能夠得到
  
三、應用場景
    雖然使用緩存效率是非常高的，但并不是所有場景都適用，因此千萬不要極端的將所有函數都添加緩存

    以下幾種情況下，適合使用緩存：

    對于昂貴的函數調用，執(zhí)行復雜計算的函數
    對于具有有限且高度重復輸入范圍的函數
    對于具有重復輸入值的遞歸函數
    對于純函數，即每次使用特定輸入調用時返回相同輸出的函數

、內存泄漏