Session有些侷限制性，或者說是一些缺點吧。現在我們再來看看Session的缺點： 　　

①當mode="InProc"時，也就是預設設定時，容易丟失資料，為什麼?因為網站會因為各種原因重啟。 　　

② 當mode="InProc"時，Session儲存的東西越多，就越佔用伺服器記憶體，對於使用者線上人數較多的網站，伺服器的記憶體壓力會比較大。 　

③當mode="InProc"時，程式的擴充套件性會受到影響，原因很簡單：伺服器的記憶體不能在多臺伺服器間共享。 　　

④雖然Session可以支援擴充套件性，也就是設定mode="SQLServer"或者mode="StateServer"，但這種方式下，還是有缺點：在每次請求時，也不管你用不用會話資料，都為你準備好，這其實是浪費資源的。 　　

⑤ 如果你沒有關閉Session，SessionStateModule就一直在工作中，尤其是全採用預設設定時，會對每個請求執行一系列的呼叫。浪費資源。 　　

⑥併發問題，前面有解釋，也有示例。 　　

⑦當你使用無 Cookie 會話時，為了安全，Session預設會使用 重新生成已過期的會話識別符號 的策略，此時，如果通過使用 HTTP POST 方法發起已使用已過期會話 ID 發起的請求，將丟失傳送的所有資料。這是因為 ASP.NET 會執行重定向，以確保瀏覽器在 URL 中具有新的會話識別符號。 　　

不可否認的是，或許有些人認為這些缺點是可以接受的，他們更看中Session的簡單、易使用的優點，那麼，Session仍然是完美的。 不使用Session的替代方法 　　

對於前面我列出的Session的一些缺點，如果您認為你有些是不能接受的，那麼，可以參考一下我提出的替代解決方法。 　　

①如果需要在一個頁面的前後呼叫過程中維持一些簡單的資料，可以使用元素來儲存這些資料。 　　

②您希望在整個網站都能共享一些會話資料，就像mode="InProc"那樣。此時，我們可以使用Cookie與Cache相結合做法，自行控制會話資料的儲存與載入。具體做法也簡單：為請求分配置一個Key(有就忽略)，然後用這個Key去訪問Cache，以完成儲存與載入的邏輯。如果要使用的會話資料數量不止一個，可以自定義一個型別或者使用一個諸如Dictionary, HashTable 這樣的集合來儲存它們。很簡單吧，基本上這種方式就是與mode="InProc"差不多了。只是沒有鎖定問題，因此也就沒有併發問題。 　　

③ 如果您想實現mode="StateServer"類似的效果，那麼可以考慮使用memcached這類技術，或者自己寫個簡單的服務，在內部使用一個或者多個Dictionary, HashTable來儲存資料即可。這樣我們可以更精確的控制讀寫時機。這種方法也需要使用Cookie儲存會話ID。 　　

4. 如果您想實現mode="SQLServer"類似的效果，那麼可以考慮使用mongodb這類技術，同樣我們可以更精確的控制讀寫時機。這種方法也需要使用Cookie儲存會話ID。如果您沒用使用過mongodb，可以參考我的部落格： MongoDB實戰開發  　　從前面三種替代方法來看，如果不使用Session，那麼Cookie就是必需的。其實Cookie本身就是設計用來維持會話狀態的。只是它不適合儲存過大的資料而已，因此，用它儲存會話ID這樣的資料，可以說是很恰當的。事實上，Session就是這樣做的。 　　推薦方法：為了保持網站程式有較好的擴充套件性，且不需要儲存過大的會話資料，那麼，直接使用Cookie將是最好的選擇。 　　由於Cookie儲存在瀏覽器，且不安全，所以建議只儲存諸如：id, key 之類的簡單資料，需要其它的會話資料時再根據這些id, Key去獲取。 　　到這裡，我想我可以回答標題中的問題了：Session，其實是沒有必要使用的，不用它，也能容易地實現會話資料的儲存 --------------------- 本文來自 MsdnWoo 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/MsdnWoo/article/details/51567055?utm_source=copy