前端開發初學者必讀：了解各種「狀態」的分類與來源

更新日期： 2025 年 3 月 27 日

在學習前端開發的初期，很多人會對「狀態（State）」這個詞感到困惑。

或許你曾經在 React、Vue 或其他框架中看到過 state，也知道它關乎使用者介面的變化，但你是否曾思考過：「狀態只有一種嗎？有哪些來源？我應該怎麼管理？」

其實，在一個現代 Web 應用中，狀態可以有很多種不同的來源與類型。

理解這些狀態，能幫助你更清楚地設計資料流、選擇合適的狀態管理工具，並打造更穩定、可維護的應用程式。

這篇文章將帶你系統性地認識各種「狀態」的分類與來源，讓你不再把所有狀態混在一起，而是開始有邏輯地區分 「前端狀態」 與 「伺服器狀態」，為日後深入學習打下基礎。

---

狀態是什麼？一段簡單的定義

狀態指的是「應用在某一時刻所儲存的資訊」，這些資訊會隨著使用者的操作、伺服器回傳、時間推移等因素而改變。

簡單來說，只要是會改變的資料，就可以算是一種「狀態」。

舉例來說：

• 使用者輸入的帳號密碼
• 是否已登入
• 現在頁面上顯示的產品清單
• 從 API 拿回來的資料
• 表單是否提交成功

這些都是「狀態」，但來源與性質不盡相同。

---

狀態的兩大分類：前端 vs. 伺服器

在做網站或 Web App 時，你會處理很多「資料」——像是使用者輸入的東西、要不要顯示某個視窗、從伺服器抓來的商品清單等等。

這些資料，其實就是所謂的「狀態」。

但它們不是都一樣的東西，可以分成兩大類：前端狀態 和 伺服器狀態。

這個分類很重要，因為不同的狀態有不同的處理方式。

前端狀態（Client-side State）

這些是存在你自己電腦上的資料，也就是在瀏覽器中記著的東西。

它們不需要從網路上抓，也不用儲存在伺服器裡。

通常跟「畫面上要怎麼顯示」有關，或者是「使用者現在正在輸入什麼」，我們把這些稱作前端狀態。

常見的前端狀態有哪些？

🔹 UI 狀態（畫面狀態）

像是：

• 彈跳視窗（Modal）有沒有打開
• 使用者現在點的是哪個 Tab
• 送出按鈕是不是該被關閉

👉這些東西，純粹是「畫面要不要顯示」，不需要存起來，也不用送到伺服器。

🔹 表單輸入（Form 狀態）

像是：

• 使用者正在打姓名、Email、電話號碼
• 搜尋欄裡輸入的文字

👉這是使用者目前「正在打的內容」，還沒送出去時，就只是前端記著。

🔹 快取資料（暫存資料）

像是：

• 前面從伺服器載入過的產品列表
• 分頁資料、分類資料

👉雖然這些資料一開始是從伺服器來的，但我們可以「先記在前端」，這樣下次不用重新抓資料，可以加快速度。

🔹 本地儲存（Local Storage / Session Storage）

像是：

• 使用者選擇的語言（中文 / 英文）
• 有沒有看過公告（只要看過一次就不要再顯示）

👉這種資料會記在瀏覽器裡，即使你關掉網頁，下次打開還會在。

伺服器狀態（Server-side State）

這些資料是存在遠端伺服器上的，不在你電腦裡。你要透過 API 請求、連線，才能拿到這些資料。

像是訂單、會員資料、商品清單……這些不是誰的電腦都有，而是統一放在後端伺服器，大家來讀、來改。

常見的伺服器狀態有哪些？

🔹 使用者資料

像是：

• 你是誰（帳號、Email）
• 你有幾筆訂單、買了哪些東西
• 你是普通會員還是管理員

👉這些都在伺服器，要登入之後才能看到，也會根據你的身分決定你能不能做某些事。

🔹 資料庫裡的資料

像是：

• 商品清單
• 最新公告
• 討論區留言

👉這些是「大家都能看」的資料，伺服器會即時更新，例如新增一個商品、刪除一則留言，所有人看到的都會改變。

🔹 登入驗證（Auth 狀態）

像是：

• 你現在有沒有登入
• 你的 Token 是否過期

👉這個狀態有點特別，它是由伺服器判斷，但也會讓前端知道你「現在是不是登入中」，才能決定要不要顯示某些內容。

🔹 請求狀態（Async 狀態）

像是：

• 資料載入中…
• API 請求失敗（出現錯誤）

👉這類狀態不一定是資料本身，而是「你在跟伺服器溝通時，現在的進度是什麼」。

小結一下：

分類	放在哪裡？	誰管的？	例子
前端狀態	使用者瀏覽器	前端程式處理	輸入內容、UI 顯示、語言偏好
伺服器狀態	後端伺服器	後端管理、前端要請求才能拿	帳號資訊、商品資料、是否登入

這樣的分類可以幫助你搞懂：

• 哪些資料是前端可以自己處理的？
• 哪些資料一定要問伺服器？
• 資料變動時，我該更新哪一邊？

學會分辨這些狀態，會讓你寫出來的網站更有條理、更好維護，也能幫助你之後學更進階的「狀態管理工具」時更順利！

---

為什麼需要區分這些狀態？

對初學者來說，狀態看起來都只是資料：「不就是記個值而已嗎？不管資料來自哪裡，不都是顯示出來就好？」

但實際開發過程中，如果不清楚每種狀態的來源與性質，很容易出現以下情況：

• 把資料放錯地方，結果畫面更新不起來
• 同一筆資料重複請求，造成效能下降
• 前端錯誤地「改掉」應該由伺服器控制的東西，導致安全漏洞

所以，學會區分各種狀態的來源與類型，不只是理論上的分類，而是一種實務上非常有用的技能。接下來我們會從三個角度來說明原因：

更有效的狀態管理：該放哪裡，就放哪裡

在寫前端時，你會遇到很多資料來源：

• 使用者操作時產生的資料（輸入欄位內容）
• 畫面元件狀態（Modal 開關）
• 從伺服器 API 拿來的資料（商品清單）
• 使用者登入與否（需要驗證的狀態）

如果把所有這些資料通通塞進同一個狀態管理系統（例如全都放在 Redux），不但程式碼會變得複雜又難讀，還會讓你：

• 不知道哪些資料應該同步更新
• 為了拿一點 UI 狀態，卻多引入一堆不必要的結構
• 不小心「改錯地方」，導致資料失真

相反地，根據資料來源與性質分別處理，你可以這樣做：

• UI 狀態：用 React useState 或 Vue ref 簡單處理就好
• 表單資料：使用 React Hook Form 或類似工具集中管理
• 快取的伺服器資料：交給 React Query/SWR 自動管理更新與同步
• 全域共用資料：再考慮使用 Redux、Zustand 等狀態管理工具

這樣一來，每種資料都放在最合適的位置，程式更有組織，也更容易管理。

提升維護性與可讀性：讓你與團隊都能看得懂

一個應用隨著功能增加，程式碼也會越寫越多。

如果不區分狀態來源，會導致資料管理越來越混亂：

• UI 狀態與伺服器資料混在一起，誰改動會影響誰？很難判斷
• 新手進團隊時，很難理解「這個狀態是做什麼的」
• 想要新增功能時，一改就牽動一整串原本不相關的邏輯

相反地，當你一開始就將狀態依照來源與性質分開處理，例如：

• UI 顯示邏輯和畫面互動用 local state
• 伺服器同步資料由 React Query/SWR 負責
• 一些需要跨元件共享的資料才放進全域 state（Redux、Zustand）

這樣的架構就像把資料分門別類地整理在不同抽屜裡。你可以快速找到問題點，團隊夥伴也更容易理解並維護你的程式。

更安全與穩定的應用：哪些資料可以改，哪些不能動

很多初學者會誤以為「我前端顯示什麼，就表示我可以改什麼」。

但事實是：

• 有些資料是來自伺服器的「真實資料來源」（source of truth）
• 前端只是「顯示」資料，而不是「決定」資料

如果你搞不清楚這些界線，可能會發生：

• 把伺服器資料直接存在前端，讓使用者改掉它（例如價格、權限等）
• 忘記同步伺服器資料，只改了畫面，實際資料沒改變
• 更新方式錯誤，造成資料不同步或版本衝突

所以，當你知道哪些是伺服器狀態，就會特別注意這些資料的處理：

• 是否需要驗證（是否登入、有權限）
• 是否需要同步（改了之後要通知伺服器）
• 是否可以快取（多久要重新抓資料）

理解這些邊界，能幫助你寫出更安全、更穩定的應用，避免因為前端誤操作而產生漏洞。

小結：狀態分類，不只是分類

狀態分類的目的，不只是為了方便學習，而是幫助你：

能力提升面向	實際好處
開發效率	每種資料放對位置，開發更順手
團隊溝通	不同狀態清楚分離，大家都懂
系統穩定性	知道哪些資料不能亂改，減少 bug
擴充彈性	功能新增時，維護容易、變動小
技術選型	能判斷什麼情境適合用什麼工具

---

總結與延伸學習建議

📌 狀態，是前端開發的靈魂

無論你是做一個簡單的表單、操作一個按鈕，還是開發複雜的 SPA（單頁應用程式）、大型網站，你都一定會處理狀態。

狀態的變化，決定了畫面要怎麼更新、資料要怎麼顯示，也決定了一個前端應用能不能「動起來」。

掌握狀態，不只是能讓畫面運作正確，更是邁向進階開發者的重要門檻。

回顧本文重點

✅ 狀態的本質

狀態就是「應用在某一時刻所儲存的資料」，這些資料會隨著：

• 使用者操作（點擊、輸入）
• 時間推移（倒數計時、動畫）
• 外部資源回應（API 回傳）

而改變。

換句話說，只要是會變動的資料，就叫做狀態。

✅ 狀態的兩大分類

在實際開發中，我們可以把狀態依據來源，分成以下兩種：

類型	資料從哪來？	常見例子
前端狀態	使用者裝置（瀏覽器）	使用者輸入、Modal 開關、快取資料、語言偏好
伺服器狀態	後端伺服器或 API	使用者帳號、訂單記錄、商品清單、登入驗證

這樣的分類幫助我們釐清資料的責任歸屬，前端該處理什麼？後端該負責什麼？該由誰來更新？誰是資料的「真相來源（source of truth）」？

✅ 為什麼要區分？

清楚區分這些狀態，有三個非常實際的好處：

1. 選對工具，管理更輕鬆
   UI 狀態用 useState 就好，伺服器資料用 React Query 管，大家各司其職，不會互相干擾。
2. 團隊開發更容易維護
   同樣一個資料名詞，如果 UI 和伺服器都管理它，容易出現誤會。區分好，寫的人看得懂，維護的人不會頭痛。
3. 避免安全與同步問題
   例如：伺服器狀態代表「真實世界的狀況」，不該讓前端直接修改（例如使用者權限、商品價格）。

🏁 結語：先理解，再選擇

狀態管理這個主題，看似抽象，實際上卻是前端開發中每天都在面對的事情。

最重要的不是工具選擇，而是你是否知道自己在管理什麼資料、資料從哪來、要給誰用、誰負責更新。

只要你有這樣的思維，不管用的是什麼框架、什麼工具，你都能駕馭它，寫出可維護、可靠、有彈性的程式碼。