我有一個搜索結果頁面，返回大約40個圖像。我使用mongohq來存儲我的圖像。 現在這些圖像將永遠不會改變。他們將被刪除或保持原樣。客戶端緩存的空間限制
所以，我的春天的servlet從mongoHq讀取基於圖像的ID
/app/download/{uniqueImageId}
所有作品好後流的圖像。除了流式傳輸圖像的加載時間。我覺得這些圖像對於這些獨特的ID將保持不變，爲什麼不緩存它們。我可以添加一個適用於我上面的url類型的過濾器，並添加一個緩存頭，我打算給一個非常長的值，比如可能會緩存一週的圖片。
我的問題是，如果我開始告訴客戶端的瀏覽器緩存所有這些40 +圖像，它會緩存所有這些圖像？ 客戶端沒有任何空間限制嗎？
您是否看到更好的選擇來處理這種情況？
我的問題是，如果我開始告訴客戶端的瀏覽器緩存所有這些40 +圖像，它會緩存所有這些圖像？客戶端沒有任何空間限制嗎？
當然，客戶端有空間限制（全世界的存儲空間也是有限的......嗯，對不起......）。用戶可能會限制緩存空間，並且/或者瀏覽器僅自動獲取可用於緩存的可用空間。
通常我會希望瀏覽器緩存總是一些兆字節（比方說100+），因此在會話中傳輸的所需圖像（如圖標）經常會被緩存。無論圖片是否仍在緩存中，用戶在三天後訪問您的網站時，都取決於緩存大小和用戶之間的活動。所以你永遠不知道。
客戶端或任何中間代理做什麼都不在您的直接控制範圍之內。您通過設置緩存標頭所做的唯一事情就是說，暫時不刷新此資源是合法的。如果您在應用程序中設置了標頭，請確保正確理解HTTP1.1標頭。
您是否看到更好的選擇來處理這種情況？
術語「更好」在這裏不是很確切。你究竟需要優化什麼？
如果您在同一圖像集上有很多請求，可以通過將邊緣服務器（如nginx）放在您的應用程序前配置爲緩存逆向代理來減少服務器和數據庫負載。在這種情況下，您自己的邊緣服務器正在解釋緩存標頭。一般來說，如果應用程序在靜態資源服務方面沒有重大負載，我認爲這是一個很好的設計。