網頁的 Stateless（無狀態）與 Stateful（有狀態）是什麼？給初學者的完整解說

更新日期： 2025 年 3 月 27 日

在學習網頁開發或理解伺服器架構時，你一定會聽到「Stateless（無狀態）」與「Stateful（有狀態）」這兩個詞。

這兩種模式牽涉到系統如何處理用戶資料、管理使用者行為，以及維持操作流程。

這篇文章將從最簡單的角度，帶你了解這兩個名詞是什麼、差在哪裡、什麼情況該用哪一種，還有實際例子幫助你一秒看懂！

什麼是「狀態」？先搞懂 State 是什麼意思

在學網頁開發的時候，「狀態（State）」是一個你會經常聽到的概念。

但很多人第一次聽到時會覺得抽象，其實它的意思很簡單：

「狀態」就是系統或使用者在某一個時間點的資訊或條件。

你可以把「狀態」想像成一個紀錄表，紀錄著目前誰在操作、操作到了哪裡、有哪些資訊已經被填寫或選擇了。

狀態的三大關鍵點

1. 會變動：狀態是「隨時間會變化的資訊」，不像設定值是固定的。
2. 會影響結果：不同的狀態會導致不同的畫面、流程、或伺服器回應。
3. 跟使用者有關：大多數狀態都跟使用者的操作、登入身份、選擇內容有關。

實際例子幫助理解

來看看幾個在網頁中常見的狀態範例：

✅ 1. 登入狀態

• 使用者目前是否已經登入？
• 如果登入了，系統要顯示「登出」按鈕，顯示使用者名字。
• 如果沒登入，要顯示「登入 / 註冊」畫面。

👉 這就是一個典型的「狀態」：登入 vs. 未登入。

✅ 2. 購物車狀態

• 使用者目前加入了哪些商品？
• 每個商品的數量是多少？
• 加總價格是多少？

👉 這些都是購物車的「狀態」，會隨著使用者點選「加入」或「移除」而改變。

✅ 3. 表單填寫進度

• 使用者填到第幾步？
• 哪些欄位已經填寫？
• 哪些欄位驗證成功或失敗？

👉 這些資訊會影響是否可以按下一步或送出表單。

✅ 4. 遊戲中的角色狀態

• 玩家目前的血量是多少？
• 有沒有裝備某個武器？
• 正在第幾關卡？

👉 雖然這看似跟網頁無關，但同樣是「狀態」的概念，只是它發生在遊戲裡。

狀態的儲存位置

狀態可以存在不同的地方：

什麼是「無狀態」（Stateless）？

定義說明

在「無狀態」系統中，每一個來自使用者的請求（Request）都被當成全新的事件來處理。

✅ 伺服器不會記得你是誰、你來過幾次、你剛剛做過什麼，也不會知道你接下來要幹嘛。

每一個請求都像陌生人一樣被獨立處理，伺服器「不帶任何記憶」，就像一個健忘但效率很高的機器人。

🧠 用比喻幫你理解

想像你每天去超商買東西，每次排隊時，收銀員都問你：

「你好，請問你叫什麼名字？你要買什麼？有會員卡嗎？請全部重新報一次。」

即使你昨天才來過、今天穿一樣的衣服，他還是完全不記得你。

這就是「無狀態」的處理方式：每一次互動都是「第一次見面」。

真實世界的例子：HTTP 協議

HTTP（超文本傳輸協定）本身就是一個「無狀態」的協定。

意思是：

• 當你點擊一個網頁、發出一個 API 請求，伺服器不會知道你曾經發過其他請求。
• 伺服器只根據當下這一筆請求來回應你，不會根據過去或上下文判斷。

💡 舉個實際的狀況：

你打開一個購物網站，輸入帳密登入 → 登入成功後，伺服器處理完就「忘記你了」。

如果沒有額外機制（例如 Cookie 或 Token），你點下一頁時，伺服器會當你是個「新訪客」，請你再次登入。

無狀態的特色

無狀態的優點

1. 容易擴充（scalable）
   • 每台伺服器都能處理任意請求，不需要共享狀態資訊。
   • 適合部署多台伺服器做「負載平衡」。
2. 好維護
   • 因為伺服器不需要追蹤使用者狀態，邏輯單純，Bug 比較少。
3. 資源佔用少
   • 不必為每位使用者保留記憶體空間或資料結構。
4. 容錯率高
   • 即使其中一台伺服器掛了，只要請求轉給另一台，一樣能處理（因為沒狀態依賴）。

無狀態的缺點

1. 無法保留使用者狀態流程
   • 使用者每次都被當作「全新」訪客，不知道上一頁填了什麼，或上次選了什麼商品。
2. 需要額外機制補足記憶功能
   • 例如使用：
     • Cookie / Session（儲存在瀏覽器端或伺服器端）
     • Token（如 JWT）
     • LocalStorage / IndexedDB（前端記住狀態）
3. 資料必須每次都重新傳遞
   • 每個請求都要把使用者的身份資訊、驗證資訊附帶進來，否則伺服器無法辨識你是誰。

無狀態的典型使用場景

有狀態（Stateful）是什麼？

定義說明

在「有狀態（Stateful）」的系統中，伺服器會記住使用者的過去行為與當前狀況（也就是狀態），並根據這些資訊來做後續處理。

✅ 使用者每一次與系統互動，伺服器都會「記得你上次是誰、做了什麼」，讓流程可以連續不中斷。

這樣的系統就像一位貼心又記憶力超強的店員：

「你昨天點了拿鐵，加了半糖少冰，今天要一樣嗎？」

🧠 用比喻幫你理解

如果無狀態是「健忘的收銀員」，那有狀態就是「熟客專屬的店員」：

• 昨天你來買過咖啡，今天再來，店員立刻知道你的偏好。
• 你昨天沒結帳的購物車，今天打開還在。
• 你點了訂單、填了一半的表單，重新整理後還能繼續。

這些「記得你是誰」、「記得你正在幹嘛」的能力，就是有狀態系統的特徵。

常見的 Stateful 應用例子

✅ 1. 登入後的網站操作

登入一次後，你可以：

• 瀏覽多個頁面，不需要每頁都重新驗證身份
• 存取你的個人資料、訂單紀錄
• 使用購物車、追蹤清單等功能

👉 這些體驗的基礎，就是伺服器「記得你是誰」。

✅ 2. 線上遊戲

當你登入線上遊戲時：

• 系統知道你是誰（帳號登入）
• 記得你目前的角色、金幣、裝備
• 甚至知道你在哪一個地圖、打到第幾關

👉 這些都需要伺服器持續保存並更新「狀態」。

✅ 3. 多步驟表單（例如報名流程）

你填到第 3 步才發現漏填，按上一頁返回第 2 步。

• 有狀態系統會記得你剛剛填到哪裡，讓你接著填完。
• 無狀態的話，就會重來一次。

有狀態的特色

有狀態的優點

1. 使用者體驗佳
   • 登入一次後不用重複驗證身分
   • 表單流程可中斷後再繼續
   • 購物車記錄不會消失
2. 流程可控，邏輯更完整
   • 可實作「一步步進行」的多階段邏輯
   • 可以記得使用者偏好、進度、歷史紀錄
3. 適合即時互動服務
   • 線上客服、多人遊戲、股票即時行情等，都需要即時資料傳輸與狀態同步

有狀態的缺點

1. 伺服器資源壓力大
   • 每個使用者都要分配一個「狀態空間」來記憶資訊（如記憶體、資料庫）
   • 使用者越多，管理成本越高
2. 系統維護較複雜
   • 需要考慮狀態同步、狀態遺失、狀態過期等情況
   • 例如多人同時操作，狀態不同步可能出錯
3. 可擴展性差
   • 若資料存在單一伺服器上，就很難做負載分散
   • 多台伺服器之間要做「狀態共享」會變得困難（常見於大型分散式系統）

Stateful 的典型使用場景

Stateless vs. Stateful：差在哪？

當你已經理解什麼是「有狀態」與「無狀態」之後，接下來最重要的就是知道——這兩種系統究竟差在哪？分別適合用在哪些地方？

我們可以從幾個核心面向來比較它們的差異：

記不記得你？

• 無狀態：伺服器就像剛認識你的人，每一次互動都需要你自我介紹。
• 有狀態：伺服器就像老朋友，可以接著上次的話題繼續。

使用者體驗

• 無狀態系統通常用在 API 查詢、新聞網站這類「即查即得」的場合。
• 有狀態系統能記住你的登入、選擇、歷史紀錄等，帶來更流暢的使用體驗。

💡 實際情境比較：

系統資源使用量

• Stateless 系統不需要額外記憶每位使用者的資料，因此相對「輕巧」。
• Stateful 系統必須保留使用者的 session、資料或上下文，會佔用更多伺服器資源（如記憶體、CPU、儲存空間等）。

可擴展性（Scalability）

• 無狀態系統因為不需要保存資料，可以很容易用「加機器」的方式水平擴充（Horizontal Scaling）。
• 有狀態系統則需要伺服器之間共享使用者狀態，這會讓系統變得複雜而難以擴充。

🧠 舉例：

• RESTful API 可以輕鬆丟到多台機器跑，因為請求獨立不相依。
• 遊戲伺服器就不容易擴充，因為你要在每台機器上同步每位玩家的遊戲狀態。

適合的使用情境

總整理表格

Stateless 就像是一次性問答，你說什麼它就做什麼，但不會記住你說過什麼。

Stateful 則像是一段持續的對話，系統知道你是誰、上次說到哪裡，能讓互動更有邏輯與連貫性。

那我該用哪一種？Stateless 還是 Stateful？

🧠 沒有絕對答案，依情境選擇才是關鍵！

在設計系統時，並沒有哪一種一定比較好，而是要根據你的應用場景與使用者需求，來決定採用無狀態（Stateless）或有狀態（Stateful）模式。

適合使用 Stateless（無狀態）的情境

1. RESTful API 設計

HTTP 是天生的無狀態協定，因此 RESTful API 本身就是以「每次請求都是獨立的」為基礎設計。

• 每次請求都包含完整資訊（例如身份驗證 Token）
• API 不需要記住之前發生的事，只要針對請求給出對應的回應

🔧 技術搭配

通常會使用：

• JWT（JSON Web Token）
• OAuth Token
• API Key

來讓用戶在每次請求中「自我證明身份」，即便伺服器不記得你，它還是可以驗證你是誰。

2. 微服務架構（Microservices）

傳統的網站系統通常是「單體架構（Monolithic Architecture）」：

• 所有功能都寫在同一個應用程式裡（例如登入、訂單、付款、通知等）
• 一次部署、一起更新，出錯容易影響整個系統

而「微服務架構（Microservices Architecture）」的核心想法是：

把整個系統的功能 拆成許多小服務，每個服務只負責一件事，像是：

• 會員服務（處理註冊、登入、密碼管理）
• 商品服務（處理商品列表、商品上架）
• 訂單服務（處理購物流程、訂單建立）
• 通知服務（寄送簡訊、Email）

為了讓微服務架構真正發揮優點，每個服務必須「獨立且不依賴其他服務的內部狀態」，也就是：

❗ 每一個服務最好是 Stateless（無狀態）的！

為什麼這樣設計有好處呢？

✅ 1. 服務之間不會互相牽制

每個服務都是獨立的「小模組」，彼此用 API 溝通，而不是共享記憶體、資料或狀態。

• 如果「商品服務」掛了，不會影響「會員服務」
• 「訂單服務」可以在不知道你是誰的情況下，只根據「請求裡的 Token」來處理你下單

這樣就可以做到「解耦合」，讓整個系統更穩定、容易維護。

✅ 2. 更容易水平擴展（Scaling）

因為每個請求都獨立、不記狀態，所以你可以：

• 輕鬆在不同機器上開更多服務副本（Instances）
• 做負載平衡（Load Balancing），把請求平均分配給多台伺服器

例如：

有 10 萬人同時登入會員系統，你只要加 5 台會員服務伺服器就能分攤負擔，不需要擔心狀態同步問題。

✅ 3. 可獨立部署、更新、不影響其他系統

每個微服務都有自己的部署管道：

• 你可以只更新「商品服務」的程式，不需要重啟整個網站
• 不同團隊可以各自負責不同服務，開發更快、更專注

這也是為什麼很多大型系統（像是 Amazon、Netflix、Facebook）都使用微服務架構。

但如果服務是有狀態的，會遇到什麼問題？

假設你把「購物車狀態」存在訂單服務記憶體中（Stateful）：

• A 使用者連到訂單服務 1 加入商品
• 下一次請求被轉到訂單服務 2，卻不知道 A 剛剛加了什麼

👉 你就會遇到「狀態不一致」或「使用者資料遺失」的問題。

除非你另外做「狀態同步機制」（像 Redis、共享資料庫、Session Server），否則系統會變得非常難維護。

3. 簡單查詢型系統

例如：

• 新聞網站
• 公開 API 查詢
• 查天氣、匯率、股價的服務

這類系統通常不需要記住誰查過什麼，只要根據請求內容回應資料就好，非常適合 Stateless。

適合使用 Stateful（有狀態）的情境

1. 登入系統 / 後台管理平台

使用者登入後，整個網站都需要知道他的身份（例如：顯示使用者名稱、權限、個人資料等），這就需要伺服器記住「這個使用者是誰」。

常見做法：

• 使用 Session 機制
• Cookie 儲存 Session ID
• 記憶登入狀態直到使用者登出或過期

2. 即時聊天、多人遊戲、影音通話系統

這類應用需要伺服器「持續追蹤使用者的連線與操作情境」，例如：

• 哪些使用者正在對話？
• 玩家目前在哪一張地圖、血量是多少？
• 正在通話的雙方連線狀態如何？

這些場景都需要「有狀態」才能正確同步資訊與回應操作。

3. 購物車、分步填寫的表單

• 購物網站需要記得你加入了哪些商品
• 表單流程可能有多步驟（例如報名、購買、申請流程）

如果沒有記住狀態，使用者每次重新整理頁面都會從頭開始。

實際案例比較：Stateless vs. Stateful 的真實應用

理解理論很重要，但實際開發中該怎麼選？

以下我們用兩個常見的功能來具體比較有狀態 vs 無狀態的系統設計，並說明何時該用哪一種。

非常好！這一段是整篇文章中最關鍵也最容易混淆的地方，下面我幫你用更清楚的方式一步步解析「網站登入系統的 Stateless vs Stateful」，搭配更多細節、流程圖解思維、具體場景，讓你一看就懂。

網站登入系統：Stateless vs Stateful 登入到底差在哪？

「登入」看起來只是輸入帳密按下按鈕，但對系統來說，背後有兩種完全不同的運作方式：

• 🧠 Stateless（無狀態）登入：每一次請求都要「自我介紹」，伺服器不記得你是誰
• 🧠 Stateful（有狀態）登入：伺服器會「記住你」，之後就知道你是誰

📦 一、無狀態登入（Stateless Login）

📘 基本概念：

使用者登入後，伺服器會產生一組 Token（常見是 JWT） 並傳給前端，前端在之後每次發送 API 請求時，都必須主動附上這個 Token，讓伺服器知道你是誰。

伺服器本身不會保存任何登入狀態，完全依賴你給它的 Token 來識別你。

🧠 流程長這樣：

1. 使用者登入 → 輸入帳密
2. 伺服器驗證成功 → 回傳一組 JWT Token
3. 前端收到 Token，儲存在 localStorage 或 memory 中
4. 之後每一筆 API 請求，都要在 HTTP Header 中加上： Authorization: Bearer <你的JWT>
5. 伺服器每次都解讀這個 Token 來「臨時確認你是誰」，但不會保存任何登入紀錄

📌 為什麼叫「無狀態」？

因為伺服器不會記住登入紀錄，你每一次請求它都當作「第一次見面」，只靠你手上的 Token 來判斷身分。

✅ 優點：

• 高度可擴展（Scalable）：因為伺服器不保留登入狀態，所以請求可以送給任何一台機器處理。
• 前後端分離友善：API 是無狀態的，很適合串接 App、SPA、第三方系統。
• 維護簡單：不需要額外儲存使用者狀態、session 機制。

❌ 缺點：

• 安全風險需考量：Token 一旦被竊取，任何人拿著它都能偽裝你，直到過期為止。
• 無法主動登出使用者：因為伺服器不知道誰登入了，所以也不能直接強制讓誰「下線」，必須靠前端自己清除 Token。

🍪 二、有狀態登入（Stateful Login）

📘 基本概念：

使用者登入後，伺服器會建立一個「Session 物件」來儲存使用者的登入狀態，並將這個 Session 的 ID 透過 Cookie 傳給瀏覽器。
接下來每次請求，瀏覽器會自動附上這個 Cookie，伺服器根據這個 ID 找回原本的登入資訊。

🧠 流程長這樣：

1. 使用者登入 → 輸入帳密
2. 伺服器驗證成功 → 建立一筆 Session 記錄（通常保存在記憶體或資料庫中）
3. 回傳一個 Session ID 給瀏覽器 → 儲存在 Cookie 中
4. 之後每一次請求，瀏覽器會自動帶上 Cookie
5. 伺服器看到這個 Session ID，就知道你是誰、登入了沒、上次做了什麼

📌 為什麼叫「有狀態」？

因為伺服器自己會保留「使用者目前的登入狀態」這筆資料，只要你沒登出、Session 沒過期，伺服器就會記得你。

✅ 優點：

• 體驗順暢：使用者登入後不用每次傳 Token，伺服器自動記得你。
• 安全性較可控：伺服器可以主動終止 Session，例如：封鎖帳號、強制登出。
• 好管理登入邏輯：權限控管、記錄登入 IP、登出時間都容易實作。

❌ 缺點：

• 較難橫向擴展：如果有多台伺服器，Session 要「共享」，否則 A 機登入、B 機就認不得你了。
• 佔用伺服器資源：每一位登入使用者都會佔一點伺服器記憶體或儲存空間。

📦 用儲存位置比較更清楚

• Stateless Login（無狀態登入）：
  👉 狀態存在「使用者端」（瀏覽器），伺服器不記得你
  👉 Token（例如 JWT）是你用來證明身份的通行證，保存在瀏覽器中（localStorage、cookie、memory…）
  👉 每次請求要「自己拿出身份證」給伺服器看

• Stateful Login（有狀態登入）：
  👉 狀態存在「伺服器端」，伺服器記得你是誰
  👉 登入時伺服器會建立一筆 Session 資料（常儲存在記憶體、資料庫、Redis）
  👉 瀏覽器只保存一個簡單的 session ID（存在 Cookie 裡），拿來讓伺服器查你是誰

flowchart TB
  %% 主流程
  U1[輸入帳密] --> U1A[發送登入請求]
  U1A --> Auth[伺服器驗證帳密]
  Auth --> StatelessPath[無狀態登入]
  Auth --> StatefulPath[有狀態登入]
  
  %% 無狀態登入流程 - 伺服器端
  StatelessPath --> B0[產生JWT Token]
  B0 --> B0A[回傳Token給瀏覽器]
  
  %% 無狀態登入流程 - 瀏覽器端
  B0A --> U2[瀏覽器收到Token]
  U2 --> U3[儲存在localStorage]
  U3 --> U4[API請求附上Token]
  
  %% 無狀態登入流程 - 後續請求
  U4 --> B1[伺服器收到Token]
  B1 --> B2[解碼Token驗證身分]
  B2 --> B3[不儲存登入狀態]
  
  %% 有狀態登入流程 - 伺服器端
  StatefulPath --> C1[伺服器建立Session]
  C1 --> C2[儲存登入狀態]
  C2 --> C3[回傳SessionID寫入Cookie]
  
  %% 有狀態登入流程 - 瀏覽器端
  C3 --> U2S[瀏覽器收到Cookie]
  U2S --> U3S[儲存Cookie]
  U3S --> U4S[請求帶上SessionID]
  
  %% 有狀態登入流程 - 後續請求
  U4S --> C4[伺服器收到SessionID]
  C4 --> C5[查找Session得知身分]
  
  %% 分組區塊
  subgraph browser[瀏覽器]
    U1
    U1A
    U2
    U3
    U4
    U2S
    U3S
    U4S
  end
  
  subgraph server[伺服器]
    Auth
    subgraph stateless[無狀態登入處理]
      B0
      B0A
      B1
      B2
      B3
    end
    
    subgraph stateful[有狀態登入處理]
      C1
      C2
      C3
      C4
      C5
    end
  end

🧠 比喻補充：

• Stateless：你每天上班都帶一張員工證（JWT），公司不記得你昨天來過，但看到你的證件就讓你進來。
• Stateful：公司有一個打卡系統（Session），你昨天打過卡，今天來他馬上認得你，不用再證明。

線上購物車系統：Stateless vs Stateful 的差異

線上購物車是一個非常典型的「需要狀態」的功能。

「使用者加入商品後，系統要不要記得？要記多久？要記在哪裡？」

這些問題的答案，會影響購物車功能的技術設計、使用者體驗，甚至系統成本。

🔍 一、無狀態購物車（Stateless Shopping Cart）

📘 基本概念：

在這種模式下，購物車的商品資訊全部存在使用者的瀏覽器裡，例如：

• localStorage
• sessionStorage
• URL query string（少見）
• 或前端的 memory state（如 React 的 state）

🧠 行為流程：

1. 使用者點選「加入購物車」
2. 商品資訊被保存在瀏覽器的 localStorage 中
3. 使用者在頁面上可以瀏覽、修改購物車
4. 直到按下「結帳」時，才將整份購物車資料一次性送給後端 API

✅ 優點：

❌ 缺點：

🎯 什麼時候適合用 Stateless？

• 訪客可不登入直接購買（例如開架電商）
• 網站流量大，後端不想儲存所有訪客狀態
• 僅提供一次性購物流程，不強調會員行為分析

🔍 二、有狀態購物車（Stateful Shopping Cart）

📘 基本概念：

在這種模式下，購物車資料會被儲存在後端伺服器中，例如：

• 資料庫（MySQL / PostgreSQL）
• Redis（記憶體型儲存）
• 或與使用者的 Session 綁定

使用者必須登入（或以某種方式識別身份），才能將購物車內容與帳號綁定。

🧠 行為流程：

1. 使用者登入帳號
2. 點選「加入購物車」 → 商品資訊會送到後端 API
3. 後端將商品加入資料庫中、或暫存於 session
4. 使用者重新整理或換裝置，再次登入後 → 繼續看到相同的購物車內容

✅ 優點：

❌ 缺點：

🎯 什麼時候適合用 Stateful？

• 希望建立「會員系統 + 購物歷史」的完整電商平台
• 想要提供跨裝置同步、追蹤用戶行為
• 支援「加入購物車後放著，過幾天再買」的延續性

小結：Stateless vs Stateful 購物車

🧠 建議策略：兩種模式搭配使用（Hybrid）

很多網站會這樣設計：

1. ✅ 訪客瀏覽時 → 購物車存在 localStorage（Stateless）
2. ✅ 使用者登入時 → 將 localStorage 的商品「同步上傳到伺服器」（轉為 Stateful）
3. ✅ 登出後 → 再清除後端儲存，或轉為匿名狀態

這樣就能兼顧：

• 訪客也能購物（降低門檻）
• 會員能同步紀錄（提升體驗）
• 後端能分析資料（行銷應用）

常見場景與建議登入模式

在不同的網站應用情境中，應該選擇 Stateless（無狀態）、Stateful（有狀態），還是兩者混用（Hybrid）？

這裡是依據實務經驗整理出來的選擇建議，幫助你根據需求快速做判斷：

🎯 建議策略：Stateless 為主，Stateful 補足

為什麼不能全部 Stateless？為什麼不全部 Stateful？

這是因為：

• Stateless 有效率、可擴展，但無法記住你在幹嘛
• Stateful 可記住上下文，但會讓系統變重、難擴充

所以實務上，大多數現代網站會採用：

✅ 「Stateless 為主軸」：身分驗證、API 請求統一使用 JWT + RESTful
✅ 「Stateful 作補充」：在特定情境保留狀態，改善使用體驗（例如購物、表單流程）

🔧 常見組合範例

結語：掌握有狀態與無狀態，設計更好的系統

在網頁系統設計中，「狀態」是一切互動的根基。

你可以這樣記：

• 🤖 無狀態（Stateless） 就像一台「機器人」：你說什麼它就做什麼，但每次都要你重頭說一次，它不記得你是誰。
• 🧑‍🍳 有狀態（Stateful） 就像一位「熟悉你的店員」：他知道你是常客、知道你點過什麼、甚至知道你喜歡怎麼調味。

只要你掌握了這兩者的差異與應用場景，就能：

✅ 設計更有效率的 API
✅ 提供更順暢的使用體驗
✅ 寫出更好擴展、可維護的網站系統！