1. 電腦中瀏覽器緩存是什麼意思
瀏覽器緩存，是打開網頁首先需要載入到本地的圖片文字視頻等網頁文件，一般只有緩存到本地才可以流暢訪問，否則就會無法正常載入。或者就無法打開網頁了。
2. 電腦桌面數據一直載入中,清除緩存後還是不行,怎麼解決
打開電腦左下角【開始】菜單，找到【所有程序】點擊打開。在彈出的菜單欄中找到【啟動】，點擊打開將該文件夾下所有項全部刪除。
其他方法：打開開始菜單找到【運行】選項，點擊打開。在彈出的運行對話框輸入msconfig 點擊確定。在彈出的系統配置對話框，點擊上方菜單欄處【啟動】。該處是系統啟動項，將不必要的啟動程序刪除，點擊確定保存即可。
清除緩存怎麼做：首先在電腦上雙擊此電腦，找到要清理的盤符。2、滑鼠右擊，選擇屬性，接著點擊磁碟清理。3、勾選要刪除的文件，點擊確定，然後點擊刪除文件，等待清理完成即可。
3. ie瀏覽器打開首頁老緩沖怎麼辦
打開IE，找到IE的設置選項，IE10、IE11一般左上角有個設置圖標，也可以找到菜單中的工具，打開裡面會有Internet選項
IE瀏覽器緩存設置
IE瀏覽器緩存設置
打開後我們會看到有一個常規選項，一般IE的緩存就在這個選項裡面，我們需要找到歷史記錄或者類似的選項
IE瀏覽器緩存設置
我們選擇設置，進入緩存設置進行調整，Internet臨時文件中的檢查存儲的頁面的較新版本一般選擇每次訪問網頁時，這樣做就是每次訪問都是請求最新的，避免從瀏覽器中取的緩存文件，不能看到最新信息
IE瀏覽器緩存設置
使用磁碟空間一般設置為最小，設置范圍在8-1024MB之間，所以我們可以設置為8M
歷史記錄我們可以根據自己的需要設置，如果做頁面開發的話盡量設置小點
IE瀏覽器緩存設置
緩存和資料庫這個設置項可以不設置，一般都不會用到
IE瀏覽器緩存設置
以上幾項設置完成後，點擊確定，保存我們的設置，我們在流量網頁，是不是感覺不用一直刷新了
4. APP中緩存、載入與刷新機制設計【轉載】
1、為什麼要加緩存？
場景一：【等待】，在向伺服器請求新的數據時。我們讓用戶看到什麼？第一種是漂亮的等待載入頁面；第二種是緩存的內容。對於第二種，用戶可以對頁面進行操作，等待新數據時可以查看舊數據，更具有「可操作性」與「可用性」，從而減輕了從伺服器獲取數據這一動作的大小和時間長短，增強了用戶體驗。另一方面，如果內容更新的間隔較長或者用戶刷新的間隔較短，在沒有緩存的情況下，很多數據我們會多次重復的向伺服器獲取，增加了成本。
場景二：【結果】沒有聯網，或者在地鐵上網路太差無法載入數據時，如果留給用戶一個空白頁面，實在是感覺有點不負責任啊。並且很多功能在沒有聯網的情況下也有使用的可能性，比如：APP中的通訊錄，查看一些聊天記錄，通知信息，文章列表等。因為用戶打開APP不一定是要看新信息，說不定是回顧老信息（或許老信息里也有用戶之前沒看的），所以恰當的緩存可以滿足更多的用戶場景。
場景三：【金錢】有一天，一個用戶發現自己裝了某個APP後流量用的特別快，Ta可能永遠將這個APP打入冷宮了，而增加緩存正是節省流量的一個方法。雖然節省的不多或者用戶也察覺不到，但是作為一個有態度的產品經理，應該多做一些思考。
2、什麼是緩存？
緩存可分為如下幾類：
（1）app緩存。
（2）固定緩存。
（3）可手動清理的緩存。
（4）不可手動清理的緩存。
（5）臨時緩存。
其中，臨時緩存常用於一個功能頁面內，保存各欄目的緩存。同一個功能里會把子功能分為多個欄目進行劃分，每個標簽欄目下的內容在本次使用中都可保存為臨時緩存，在該功能里切換欄目，不需要重新載入數據，使用緩存顯示。
對於用戶來說，使用時達到了無縫切換瀏覽，對於伺服器來說，在短時間內數據很少會有更新，所以在一般情況下能滿足用戶的正常需求，並達到體驗優秀。
臨時緩存的清理機制是：退出該功能模塊就清除之前的緩存。也就是說下次進入該功能模塊，需要重新獲取一次數據。
很多時候我們都會用到臨時緩存，因為那些信息真的不是那麼重要，而且不需要經常反復查看，那對於那些我們經常使用而且經常需要反復查看的信息，馬海祥建議採取固定緩存，保存在本地，方便下次翻閱時不需要再一次向伺服器請求數據了。
對於固定緩存又會細分為可手動清理的緩存和不可手動清理的緩存。
第一種是我們最常見的緩存，幾乎所有產品都採用這種緩存方式。平時用戶瀏覽文章、圖集載入的數據就以這種形式緩存在本地，下次看回這篇文章、圖集時就不需要載入了。用戶也可以手動把這些緩存清理了，釋放空間。
而對於某些特殊場景，例如一些相對固定的數據，我們不願意一開始就打包進App里，這樣會占太大容量，造成產品包很大，也不願意每次進入頁面都向伺服器載入這些信息，那怎麼辦？建議的解決方法就是我們可以只載入一次就永遠存在本地了，這樣安裝包也不會大，以後也不用載入了。
3、如何清理緩存？
一般App都會在「設置」里提供一個清理緩存的功能，一鍵把空間釋放。除此之外，App最好要設計自動清理機制，可以通過兩個維度來設計這個機制。
（1）、時間
通過設定一個固定的時間，或者根據用戶使用周期靈活設定時間來清理緩存。每個產品的場景不一，用戶使用頻率不一，設定這個機制的時候就需要結合實際情況考慮了。
（2）、容量
一般是設定一個容量上限，採用堆棧的設計原理進行緩存清理，溢出堆棧的舊數據將自動清除。
1、頁面載入
方案1：單頁面整體載入
這種載入比較簡單，一般運用在頁面內容比較單一的情況下，所以直接一次性載入完所有數據後再顯示內容。其單頁面載入失敗的狀態相對來說也比較好處理。
方案2：單頁面分塊載入
這種方案的特點是，能讓用戶逐步看到內容，在這個漸進的過程中降低用戶的焦慮心理。
其中又可以分為，模塊間有關聯性的，先載入父內容，再載入子內容。如優酷，先把欄目載入出來，再載入各欄目的內容。
模塊間沒有絕對關聯性的，可獨自載入各自模塊內容，根據請求的速度不同分別顯示。這樣處理有一定幾率讓用戶在沒完全刷出數據的情況下就能找到自己需要的功能，如大眾點評、淘寶客戶端等。
框架固定，內容更新的，可先把框架顯示出來，再把各模塊的數據各自載入顯示，如各種iOS自帶應用。
這種分模塊載入的需要特別注意載入失敗的狀態，畢竟每個模塊都提示載入失敗，點擊重試是很挫的一件事，可以根據信息的優先順序來決定哪些數據失敗了採用默認狀態，哪些數據採用失敗提示。
方案3：跨頁面載入
父頁面&子頁面 or 同一app內，頁面間欄位可以復用的，在載入子頁面時不需要重新載入新數據。
方案4：預載入
這種載入方式的特點是，在載入一個頁面內容的同時，預測用戶的下一步行為，並為他下一步需要使用的頁面載入內容，使得他在下一步的操作中能立刻獲取信息而不需要載入等待。
預載入提供給用戶無縫的產品使用體驗，使得用戶在使用產品的過程中更直接流暢，沒有被打斷的感覺。
具體的例子有：
在瀏覽圖集的時候，當看到第一張的圖片時，就自動後台載入第二第三第四張圖片，用戶瀏覽完第一張圖片切換到第二張時就不會有載入等待的過程。
在瀏覽新聞列表時，就把每篇新聞的內容在後台進行預載入，用戶選擇看某篇新聞時，能立刻閱讀到內容。
但是這種方案也需要面臨很多的問題，馬海祥覺得最直接的就是流量問題，因為會自動跑掉很多用戶可能根本用不上的數據流量，所以，一般情況下馬海祥建議可以設定在wifi環境才採用這種載入模式。又或者設定載入規則，只把主要內容預載入，而部分次要內容可以在用戶真的用到的時候才載入，例如預載入新聞正文的情況，可以只載入文本信息，圖片信息等到用戶進入內頁才載入。這種預載入與分塊載入結合的方式也普遍運用在各個場景。
另外，預載入也需要時間的，他只是不在客戶端顯示給用戶，默默在後台運作而已，需要特殊考慮未載入完用戶就使用到那些信息的情況，所以在做預載入設計時需要同時考慮另一種適合該情況的普通載入方式。
預載入需要根據具體的場景來進行設計，設定好信息優先順序，綜合考慮各種類型信息的具體大小流量，整體考慮預載入的方式，這些都是需要經過精心分析思考的。
隨著網路環境的發展，預載入將成為以後產品普遍的載入方式，他提供給用戶的無縫使用體驗**地提升了產品的可用性。
2、操作載入
除了頁面的信息需要載入，頁面內的操作也是需要通過給伺服器發送請求記錄的。
方案1：載入層
進行一個操作後，彈出模態的提示層，告知用戶正在載入。採用模態的提示主要是防止用戶在該過程中進行其他操作，導致當前載入出錯。由於採用模態的提示，並且有可能因為網路原因導致長時間處於載入狀態，建議提供一個「關閉」的操作，中止本次載入，恢復App可用狀態。載入失敗時可在當前浮層變換為失敗提示。模態提示層是最穩妥的方式，但他會使用戶在使用過程中有打斷的感覺。
方案2：控制項自身載入狀態
這種方式是把操作載入的狀態與控制項的樣式結合起來了，對某個控制項進行操作後，控制項變換為載入狀態，此時控制項不能重復操作。由於這種載入方式是控制項的自身狀態，不影響其他操作，所以用戶也可以對頁面進行其他操作，可能會導致同時有多個請求的情況，增加了載入失敗的風險，這也算是這種方式的弊端，不過這種極端情況很少出現。請求失敗後，可配合Toast提示告知用戶失敗的原因。
方案3：後台載入
用戶在操作後，客戶端立刻反饋操作成功，然後把請求放到後台與伺服器交互，這一過程用戶不需要了解，不需要等待，在正常情況**驗是非常棒的。
但是在極端情況下會出現一些莫名其妙的狀況，由於是後台記錄請求並與伺服器交互，所以實際請求是否成功客戶端是不說明的，全部以操作成功來顯示，這就會導致用戶誤以為操作成功了，但實際上下次來看發現沒有成功。
所以，這種載入方式是需要根據具體使用場景來權衡使用的，對於一些重要的操作，建議還是使用模態的方式載入，對於一些小操作，如點贊、訂閱、關注，可採用後台載入的方式。
3、下一頁載入還是當前也載入
用戶進入首頁，正式邁出體驗的第一步，接下來迎接的就是基於用戶目標的界面間跳轉。完成界面的跳轉，會有各種載入策略，但無論形式如何，我們都可以將其歸為兩大類：「下一頁載入」、「當前頁載入」。
（1）「下一頁載入」滿足了用戶提前窺視的需求
我們把頁面看成「點」，頁面流是連接這些點的「線」，我們以「用戶想買一條牛仔褲」這一場景作為案例做了簡單的眼動研究，從應用啟動到商品瀏覽再到商品確定最後進入下單頁，用戶所呈現的瞳孔梯次增大，即E>D>C>B>A，為了解釋這一現象，通過與被試交流，我們發現相比於各種瀏覽，用戶更期待看到他們想看到的東西。因此此時的」下一頁載入「正好，滿足了用戶提前窺視的需求。
（2） Wait！I Need Think Think
我們以同樣的方式又對「使用支付寶對手機充值」這一場景做了研究，從開始支付到二次確認支付，用戶所呈現的瞳孔都比較大，即A與B近似相等，通過訪談，我們發現與「遞增體驗流」不同的是，當用戶遇到判斷邏輯的界面時，用戶並非急於想看下一頁面到底包含怎樣的內容，而是非0即1的驗證心態，即我的操作效成功了嗎？因此在判斷邏輯界面中，用戶的內容窺視需求並不強，當然也沒什麼內容，要麼僅是一個小小的Toast，再大一點就是一個簡單的信息反饋界面（意味著「下一頁載入」在這里就是個雞肋），用戶反而對非0即1的驗證需求較為強烈，其中還伴隨著等待結果過程中的緊張感、激動感，因此界面通過 當前頁載入 表明系統正在努力地處理用戶交代的指令**了用戶的緊張感、激動感，直到結果顯現——「處理成功」，完成了非0即1驗證的滿足感。
4、先載入還是先展示
當需載入的是功能時，可以先展示再載入，當需載入的是內容時，則反過來。
淘寶
打開APP的第一個頁面是功能，所以先展示再載入的：
隨便點擊一個模塊（不要點菜單），下面要展示的將要是內容（商品），所以是先載入再展示的，沒有載入完都不展示：
京東
同樣的，功能模塊先展示後載入：
內容先載入，沒載入完不展示：
兩種方式各有利弊：
先展示，後載入：
優點：給用戶0等待的錯覺
缺點：當前數據有可能是錯的，而且得等用戶操作到最後一步才會發現
先載入，後展示：
優點：保證數據的質量和准確
缺點：網路不好時，造成等待
顯然，功能模塊對於一個產品來說是既有固定的，在短時間內幾乎不會更新，所以這種數據出現錯誤或與當前狀態不同的幾率小得多，因此，可以使用先展示後載入的方式。
另一方面，內容（特別是商品數據）是最容易產生變動的，為了保證每一個消費者看到的數據都是最真實，最准確的，所以務必要先載入再展示。
1、空白頁面刷新失敗有提示
現在的應用都標榜以內容為中心，所以都會極力避免空白頁面的出現。對於大部分的應用，最好的方法就是使用緩存，進入頁面之後，先顯示之前的緩存，然後再進行內容的刷新。其次，消滅空白頁面的第二種方法就是提供系統推薦項進行替代。但是對於一些頁面，頁面內容跟用戶的使用狀態關系密切，無法避免會出現空白頁面，這時候會使用一些引導類的提示，使得頁面變得更加豐富，同時可以促進用戶產生內容。
但是一些資訊類應用，比如讀讀日報，打開默認是空白頁面，然後再載入內容（我不是很明白這種設定）。其他一些應用，比如：豆瓣一刻和MONO，每天第一次進入應用的時候也會出現空白頁面。我猜想第二類應用的展示方式的原因是這樣的。他們的內容**都是嚴格以天為單位的，每天固定時段**精選內容。他們會希望你每天只看並且看完當天的東西，所以一旦到了第二天，昨天的內容就是累贅了。所以每天第一次進入應用的時候會出現空白頁面，象徵著每天都是從新開始。此時就會對應一個「空白刷新」邏輯。
空白刷新對應的場景是這樣子的：用戶想要刷新出內容，並且用戶知道這里可以刷出新內容，但是沒有刷新成功，這時候需要給用戶一個交待。所以需要提示用戶。同時，提示完用戶之後需要給用戶一個解決方法，這就是「點擊後重試」。
2、緩存頁面刷新失敗無提示
常見的應用比如知乎、網易新聞、好奇心日報、微信朋友圈等，這些應用都會採用緩存的形式，打開之後顯示的是緩存內容，然後系統會給伺服器發送請求，如果有內容更新的話就會自動更新一次內容，更新之後的內容直接覆蓋當前的內容。更新失敗之後是沒有提示的。但是有一些應用，比如有道詞典、企鵝FM、網易雲音樂等，他們更新失敗之後是有提示的。
我覺得這兩種應用的區分點在於
應用的使用頻率；
內容的時間連續性；
界面之間的關系緊密度。
比如說網易新聞，作為一個打發時間的工具，每天使用頻率就會比較高，所以用戶進來之後是想看看有沒有更新。其次，網易新聞的內容是連續不斷更新的，所以用戶會知道當前顯示的內容是我看看過並且處理過的。最後，新聞列表頁面顯示的是摘要，用戶可以通過摘要快速進行判斷是否要進入詳情頁，摘要有助於幫助用戶回憶上一次的使用場景。
所以這就對應著一個這樣的場景：用戶只是想看看有沒有更新，所以他們已經做好了「沒有新內容」的心理預期，所以即使是更新不了內容，用戶也不會想太多。反倒是，如果進行了錯誤提示，用戶可能會有一種挫敗感。因為他知道現在有內容，只是因為網路的原因而沒有更新，他要進行的任務受到了外界因素的阻礙，由此產生一種細微的挫敗感。
3、緩存頁面刷新失敗有提示
另一類應用，使用頻率沒那麼高，或者內容不具備時間連續性的，又或者說當前界面無法喚起用戶上一次的使用場景。那麼就有必要進行率先你失敗提示了。
比如說企鵝FM，音頻類的應用註定使用不會那麼頻繁，因為通過視覺接收的信息會比通過聽覺接收的信息更快更多，同時音頻類對環境的要求較高（比如用耳機時要求環境不那麼嘈雜，外放時要求在私人場所）。其次，此類應用都是實時推薦的，不存在時間連續性的問題，用戶無法通過時間來判斷內容是否被閱讀過。再者，標題也無法幫你快速做出判斷，你還是要進去聽過才知道內容是什麼。最後如果不提醒，用戶進入到詳情頁再收到提醒，就會覺得應用浪費了用戶的時間。所以，對於此類內容，刷新失敗是有必要進行提醒的。
5. ☆前端優化：瀏覽器緩存技術介紹
在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在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， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。
如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：
6. 如何可以讓網頁瀏覽器把網頁的緩沖頁載入到內存中，加快查看網頁的速度
用ramdisk虛擬一個內存檔，然後把ie的臨時文件（緩存）放在這個盤上。只要你的網速夠快，你的瀏覽動作基本上是即開即得的，不需要等待（寫盤）。這樣做不但提高了瀏覽速度，而且減少了上網時候對磁碟頻繁的讀寫動作，延長磁碟壽命。
以此類推，還可系統的變數（臨時儲存文件）都設置到這個盤上面，系統的速度也將得到改善，同樣減少了一定量的磁碟讀寫動作。
優點：大大提升速度，延長硬碟壽命；
缺點：若設置不正確，會導致內存溢出，系統崩潰，直接藍屏。（致命缺點）
