摘要：的兼容性由于是現代的技術，以下的古老瀏覽器是不支持的。當然也可以手動指定文件這些瀏覽器都不能直接使用緩存，即可能會要求你重新驗證，或者直接使用服務器文件。

親，如果你還在為你沒網打開不網頁而煩惱嗎？
親，你還在為你web服務器復雜的配置項而蛋疼嗎？
不要998，manifest抱回家~
manifest自H5橫空出世以來給前端網頁的瀏覽帶來了翻天覆地的變化，以前我們的網頁必須在有網的前提下打開(主要還是打開HTML), 但是現在，我們可以offline 瀏覽。 可以算是實現web app的一個特技。
manifest的兼容性 IE9+. 由于是現代的技術，IE9以下的古老瀏覽器是不支持的。所以，manifest主要應用是針對現代瀏覽器或者手機端更多一些。

瀏覽器檢測你是否使用manifest特技時，是檢測html標簽.

當解析你的HTML時，發現存在manifest文件時，則會進行如下的操作:

(from alloy team)
manifest文件可以是任意后綴比如. usable.manifest||usable.mf等，但是他的MIMEtype必須設置正確.
記住，這個時候manifest會將HTML文件也一并保存，這需要注意。

一個簡單的demo:

CACHE MANIFEST
#version 1.3
/public/static/index.css
/public/static/header.css
NETWORK:
*
FALLBACK:
/userInfo/ /404.html
#額外需要添加的緩存文件
CACHE:
images/logo1.png
images/logo2.png

基本樣式就是上述

第一行必須是指定頭即, "CACHE MANIFEST"(不能有其他的). 表示哪些文件需要緩存。如果是相對路徑則是，在manifest文件所在的目錄下。而且，不能使通配符!!!(tm 你是還不是傻). 所以一般而言只能一個一個配置.

CACHE MANIFEST
#相對于manifest文件所在的目錄
    ./index.css 

注釋: 注釋使用#+"info"
可以對緩存文件性質進行適當的說明。緩存后的文件，就會被帶上Expires的頭，表示可以不經過服務器驗證直接使用本地文件。所以，返回status Code 為 200.
另外,CACHE 定義的文件內容，和CACHE MANIFEST 是一個效果，只是跟在CACHE MANIFEST之后，就可以省略書寫CACHE，你添加上也可以。

CACHE MANIFEST
#version 1.3
CACHE:
/favicon.ico

而且CACHE可以放在文中的任意位置，不過一般都是放開頭，或者省略.

CACHE MANIFEST

# 緩存文件
index.html
css/style.css

NETWORK:
*

# 額外的需要緩存的文件
CACHE:
images/logo1.png
images/logo2.png
images/logo3.png

這里設置不使用緩存的文件，可以使用通配符"*"等。
* 表示，除了CACHE MANIFEST定義的文件之外的文件都不能被緩存。
當然也可以手動指定文件:

NETWORK
*
http://www.example.com/index.html
http://www.example.com/header.png
http://www.example.com/blah/blah

這些瀏覽器都不能直接使用緩存，即,可能會要求你重新驗證，或者直接使用服務器文件。

這個tag,可用可不用。 用來表示，指定文件無法加載時，使用另外的文件代替。參數有兩部分構成，第一部分是指定資源(可能存在文件未加載),第二部分是替代資源

FALLBACK:
/index.html /404.html
/static/* /404.html
/images/* /NotFound.jpg

當index.html無法加載時，使用404.html代替. 這里有個要求，兩個路徑必須使用相對路徑并且與清單文件同源。

這算是一個附加屬性吧。通常設置內容就只有:

SETTINGS:
prefer-online

表示，在有網的情況下，會先訪問服務器的文件，看有沒有更新，相當于設置了Cache-Control:max-age=0,must-revalidate; + ETag||Last-modified. 不過，比較stupid的是，只有FF(Opera 12)支持.

而在服務器端，需要對manifest文件的MIME設置正確。這里以nginx為例, 具體設置一下MIME type

type{
  image/gif                             gif;  
  image/jpeg                            jpeg jpg;  
  application/x-javascript              js;  
  }

詳情可以參考: manifest文件配置

這里以gulp為例。 可以在npm里面很容易找到gulp-manifest這個生成插件.
直接下載:

npm install gulp-manifest --save-dev

然后在gulpfile里面配置:

gulp.task("manifest", function(){
  gulp.src(["build/**"], { base: "./" })
    .pipe(manifest({
      hash: true,
      preferOnline: true,
      network: ["*"],
      fallback:["/images/* /404.html"]
      filename: "app.manifest",
      exclude: "app.manifest"  //不保存manifest，不過有沒有效果一樣
     }))
    .pipe(gulp.dest("./"));
});

接著就會在目錄下生成app.manifest文件，里面就是一些基本的文件格式了。另外如果你想查看你電腦有多少網頁是manifest，可以直接訪問 chrome://appcache-internals/.

manifest對于單頁應用可謂是如魚得水，但是，到了多頁應用的層面，他的bug真的是暴露無遺。

1.頁面保存的復雜度，
2.文件的及時更新，
3.緩存文件的設置, 
4.死都會保存HTML,
5.文件下載出錯，則這次更新緩存失敗,
6.覆蓋所有緩存頭，除了Cache-Control:no-store
7.在Android 4.4的webview里，關閉之后會丟失cache
8.IE10不能很好的支持FALLBACK部分.

所以，appCache的bug也是非常多的。
例如，長尾更新問題，當你的頁面保持在線的時候，是無法檢測文件已經更新，除非你reload頁面，但是用戶并不知道你已經更新，所以這里我們需要引進js的提供的緩存檢測API.

這是前端能夠摸到緩存最真實的API。我們可以通過這個API接口獲取到我們很多想要的東西:

var appcache = window.applicationCache;
console.log(appcache.status); //檢查當前緩存狀態
console.log(appcache.IDLE); //緩存狀態常量，下面解釋

window.applicationCache.update()  
//update方法調用時，頁面會主動與服務器通信，檢查頁面當前的緩存是否為最新的，如不是，則下載更新后的資源

window.applicationCache.swapCache()  //updateready后，更新到最新的應用緩存

通常結合上述兩個方法和相應的屬性我們可以手動觸發文件的更新(前提是 manifest文件改動).

var appCache = window.applicationCache;

appCache.update(); 
//檢查更新

if (appCache.status == window.applicationCache.UPDATEREADY) { 
//如果存在更新，并且已經下載ok,則替換瀏覽器緩存
  appCache.swapCache();  
}

但是，此時頁面并不能用上最新的文件，只是瀏覽器的緩存已經改變，網頁實際內容還是原來的內容，還需要手動進行reload，才能進行更新文件

window.addEventListener("load", function(e) {

  window.applicationCache.addEventListener("updateready", function(e) {
    if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
      if (confirm("文件有更新，手否重新加載文件")) {
        window.location.reload();
      }
    } else {
      //如果，拒絕則不刷新網頁
    }
  }, false);

}, false);

相關事件有: checking,downloading,updateready,obsolete,cached,error,noupdate,progress.
對照上述的status就可以很容易知道每個事件對應的效果是神馬。 需要說的就是:

progress: 當瀏覽器在下載資源時，每下載成功一次，就會觸發一次
noupdate:當瀏覽器檢查更新之后發現沒有資源更新的時候觸發這個事件
error: 更新出錯時會觸發，比如文件無法正常下載，manifest文件被刪除.

其實，使用manifest的時候，無外乎就是3種常用狀態

第一次訪問頁面時

再次訪問頁面時，沒有更新

再次訪問頁面時，有更新

每次，觸發的事件順序為:

上面看不懂沒關系，我們可以看看更直觀的Console的內容。

第一次訪問頁面時

checking->downloading->progress(多次)->cache

2. 再次訪問頁面時，沒有更新

checking->noupdate

3. 再次訪問頁面時，有更新

checking->downloading->progress(多次)->updateready

其實，manifest就是為了離線應用而生的，但是由于設計之初，沒有很好的規范，導致現在manifest的bug，真的超級多。
看到whatwg上面說的一句話，真的更加蛋疼.

This feature is in the process of being removed from the Web platform. (This is a long process that takes many years.) Using any of the offline Web application features at this time is highly discouraged. Use service workers instead.

意思就是讓你不要用manifest，應該他遲早要被fire的，但是，這一天還有很多年，很多年。 另外一個替代方案就是使用SS，但是兼容性，真的極其差。幾乎現在的瀏覽器都沒有實現(除了布道師FF實現了部分). 現在我們真的很尷尬，不過，目前的情況而言，in my opinion, 是十分推薦使用的(也沒有其他的辦法了). 那該怎么做，才能將manifest的Bug減到最低呢？
推薦的做法是將邏輯頁面和用戶數據給分離開。 邏輯頁面使用app cache，而用戶數據可以保存在web Storage || indexDB 等瀏覽器數據庫里，動態更新data時，使用web Socket,ajax,SSE等技術.