在用 ASP.NET MVC 3 重寫博客園網(wǎng)站首頁時，特地留意了一下這個緩存問題，通過這篇博文分享一下。

在 ASP.NET MVC 3 中如果使用了 OutputCache，一定要在 Action 中添加下面的代碼，切記！

Response.Cache.SetOmitVaryStar(true); 

這是一個伴隨ASP.NET從1.0到4.0的OutputCache Bug，ASP.NET MVC 3 是基于 ASP.NET 4.0 的，所以也躲不過。

問題演示

下面先來體驗一下不加 Response.Cache.SetOmitVaryStar(true); 的情況。

示例Action代碼

[OutputCache(Duration = 120)]  
public ActionResult SiteHome(int? pageIndex)  
{  
    ...  
} 

注：OutputCache.Location的默認值是OutputCacheLocation.Any（服務端、客戶端、代理服務器端等都進行緩存）

第一次請求：

第二次請求（F5刷新瀏覽器）：

第三次請求（F5刷新瀏覽器）：

接著第四次請求會返回304，第五次請求又返回200。。。

再體驗一下加 Response.Cache.SetOmitVaryStar(true); 的情況。

[OutputCache(Duration = 120)]  
public ActionResult SiteHome(int? pageIndex)  
{  
    Response.Cache.SetOmitVaryStar(true);  
    ...  
} 

第一次請求：

第二次請求（F5刷新瀏覽器）：

第三次請求（F5刷新瀏覽器）：

注：只要在緩存有效期內，服務器一直返回304。

問題分析

1. 200與304的區(qū)別

當返回狀態(tài)碼是200時，服務器端會將當前請求的整個頁面全部發(fā)送給客戶端（消耗下行帶寬）。

當返回狀態(tài)碼是304時，由于客戶端瀏覽器提供的 Last-Modified 時間在服務器端的緩存有效期內，服務器端只發(fā)送這個狀態(tài)碼，不發(fā)送頁面的任何內容（幾乎不消耗下行帶寬），瀏覽器直接從本地緩存中獲取內容。

所以，304的好處就是節(jié)約帶寬，響應速度更快。

2. 對服務端緩存的影響

加不加 Response.Cache.SetOmitVaryStar(true)，服務端的緩存情況都是一樣的。只是不加 SetOmitVaryStar(true) 時，對于同一個客戶端瀏覽器，每隔一次請求，服務器端就不管客戶端瀏覽器的緩存，重新發(fā)送頁面內容，但是只要在緩存有效期內，內容還是從服務器端緩存中讀取。

問題危害

ASP.NET 緩存的這個詭異行為，讓你在不知不覺中浪費了帶寬資源。

感想

用 ASP.NET 開發(fā)多年，這個伴隨 ASP.NET 從 1.0 到 4.0 的 OutputCache Bug 自己竟然在去年才發(fā)現(xiàn)。之前測試時第一次請求后按F5看返回304就以為沒問題，而問題恰恰就在下一下F5，偶爾多按一下F5出現(xiàn)200也沒特別留意。由此可見，細心對程序員來說是多么重要，很多bug、很多性能問題往往不是水平不夠，而是不夠細心。

優(yōu)秀的程序員都是細心的人，不僅在寫代碼的時候細心，在生活中也同樣細心。別看他木訥的樣子，你對他所做的一切，他都會細心地觀察到、體會到。做細心的程序員，珍惜細心的程序員！

原文鏈接：http://www.cnblogs.com/dudu/archive/2012/08/27/asp_net_mvc_outputcache.html