你一定遇過這種情況：打開訊息 App，列表上某個聊天室顯示「未讀 3」，點進去明明都滑到底了，回到列表卻還是顯示未讀；或是你在手機上看完了訊息，平板卻還跳紅點；又或是客服系統後台寫著「總訊息 128」，但未讀計數忽高忽低，導致主管問你「到底還有多少訊息沒回？」你一時間也說不清楚。
這些混亂幾乎都跟兩個概念有關：Unread（未讀數）和Total Messages（總訊息數）。表面上它們只是兩個數字，實際上背後牽涉到「狀態更新怎麼運作」、「多裝置同步」、「推播徽章更新」、「群組聊天室計數規則」以及「網路延遲或離線快取」。
這篇文章會用繁體中文（台灣語境）把概念拆開，從使用者視角到系統設計視角，一次講清楚：未讀與總數到底差在哪裡？為什麼會對不上？哪些規則才合理？你該怎麼設計或排錯，才能讓狀態更新看起來一致、可信、可解釋。
先把核心定義講清楚：Unread 與 Total 分別代表什麼？
Total Messages（總訊息數）通常指「這個聊天室或對話串中，系統目前已知的訊息總量」。它包含你已讀、未讀、甚至你可能根本沒滑到的更早訊息。只要訊息存在於系統（或被你裝置同步到），就算你不看它，它也算在總數裡。
Unread（未讀數）則是「在某個計數規則下，被判定為你還沒讀的訊息數量」。關鍵字是「某個規則」，因為未讀的判斷可以有不同做法：以最後閱讀位置（read cursor）為準、以已讀回條（read receipt）為準、以你是否曾進入聊天室為準、或以推播已送達但尚未確認已讀為準。不同做法會造成你看到的未讀數不同。
所以你常看到的現象是：總數幾乎只會單向增加（或偶爾因刪除而減少），但未讀數會上下跳動，因為它隨著「狀態」變化而變化。
訊息狀態更新的基本流程：從送出到你看到「已讀」
要理解未讀為什麼會亂，先要知道訊息狀態通常怎麼走。多數訊息系統大致有這些節點：
- Sent（已送出）：發送端把訊息送到伺服器（或送到對方裝置）。
- Delivered（已送達）：接收端裝置已收到訊息（或至少伺服器確認對方可接收）。
- Read（已讀）：接收端「實際讀到」訊息，並回報給系統。
- Acknowledged / Synced（已確認／已同步）：狀態回報完成後，其他裝置或其他用戶也同步到相同狀態。
未讀數通常介於「已送達」與「已讀」之間：訊息到達你這端，但你還沒被判定為已讀。問題在於「已讀」怎麼判定，以及回報是否成功、是否延遲、是否跨裝置同步。
為什麼未讀數會跟你想的不一樣？常見的 7 種原因
1) 你以為「看過」= 已讀，但系統以「讀到某個位置」為準
很多聊天室用的是「閱讀游標（read cursor）」概念：系統記錄你最後讀到哪一則訊息（例如最後可見訊息的 ID 或時間戳）。未讀數就等於「游標之後的訊息數」。
如果你只是點進聊天室但沒有滑到底、或訊息列表尚未載入到最新、或畫面停在中間位置，系統可能認定你還沒讀到最新，因此未讀數不會歸零。
2) 你滑到底了，但已讀回報沒有成功送出（離線、背景、權限）
手機可能在你滑到底的那一刻剛好網路不穩、App 進入背景、或省電模式限制背景網路，導致「已讀狀態回報」沒有送到伺服器。你本機看起來像已讀，但伺服器仍認定未讀。
這會造成典型的跨裝置差異：手機看似歸零，但另一台裝置仍顯示未讀，因為它以伺服器狀態為準。
3) 多裝置同步延遲：A 裝置已讀了，B 裝置還沒同步到
未讀狀態通常是伺服器統一管理，但同步到每台裝置仍需要時間。有些系統使用長連線（WebSocket）即時推送，有些用輪詢（polling），有些依賴推播喚醒 App 才更新。不同機制下，B 裝置晚幾秒或晚幾分鐘更新都很常見。
4) 群組聊天室的未讀計數更複雜：你讀了，但「提及」或「回覆你」仍算未處理
有些產品會把「未讀」跟「待處理」混在一起。比如群組裡有人 @你，系統即使判定你已讀到最新，仍可能保留一個提示或紅點，因為它想提醒你「你被點名了」。這在使用者感受上會像「明明讀完了怎麼還有未讀」。
5) 推播徽章（badge）與 App 內未讀是兩套系統
手機桌面上的紅點數字，很多時候不是 App 自己算的，而是推播伺服器或作業系統依照你最後收到的通知數累積。就算你在 App 內已讀，徽章數仍可能不會立刻歸零，除非 App 主動更新徽章或系統同步到最新狀態。
6) 訊息「總數」的來源不同：伺服器總數 vs 本機已載入總數
你看到的 Total 有時候是「伺服器總數」（包含尚未拉下來的歷史訊息），有時候是「本機已同步的訊息數」。如果你的列表採用分頁載入，總數可能會先顯示伺服器估算，等你往上滑載入更多歷史訊息才逐步對齊。這會讓你覺得總數怪怪的。
7) 你有刪除、封存、過濾：總數仍存在，但未讀被隱藏或重算
某些系統的總數包含被你隱藏或封存的訊息，未讀數則可能只對「目前可見的收件匣」計算。結果是：總數看似很大，但未讀很小；或你切換篩選器（例如只看未讀）後數字又變。
工程視角：未讀計數常見的三種模型
如果你在做產品或後台，最重要的是先選定「未讀如何定義」。常見有三種模型，各有優缺點。
模型 1：以「最後已讀訊息 ID」當游標（Read Cursor Model）
- 作法：每個對話對每個用戶存一個 last_read_message_id（或時間戳）。未讀數 = 大於該 ID 的訊息數。
- 優點：計算直觀、狀態單一、跨裝置同步容易解釋。
- 缺點：需要確定何時更新游標（進入聊天室就更新？滑到最新才更新？可見範圍更新？）。若 UI 或載入策略不一致，使用者容易覺得「我明明看過」。
模型 2：以「每則訊息是否已讀」做逐筆標記（Per-Message Read Model）
- 作法：每則訊息對每個用戶都有讀取狀態，未讀數就是未讀的筆數。
- 優點：精準、可以支援更多玩法（例如只把特定類型訊息算未讀）。
- 缺點：儲存與同步成本高，群組大、訊息多時維護很吃資源。
模型 3：事件／通知導向（Notification/Event Model）
- 作法：未讀不一定對應訊息筆數，而是對應「你還沒處理的事件」，例如 @你、回覆你、系統提醒。
- 優點：更符合「需要你注意」的產品目標，適合工作協作或客服系統。
- 缺點：使用者會覺得跟一般聊天不一樣，容易把它誤認為訊息未讀。
很多 App 會混合使用：訊息未讀用游標模型，但另外加一個「重要事件」紅點，兩者疊加在 UI 上就會造成誤解。要避免混亂，最重要的是在文案與 UI 層級把含義說清楚。
產品視角：什麼時候應該把未讀歸零？三種常見策略
策略 A：進入聊天室即歸零（Entry-Based Read）
你只要點進聊天室，系統就把最新訊息視為已讀。這種做法最符合「減少紅點焦慮」，也最不容易讓使用者覺得卡住。但它的問題是：你可能根本沒看到內容，狀態卻已經變成已讀。
策略 B：滑到最新／看到最後一則才歸零（Scroll-To-Bottom Read）
這種做法更嚴謹，尤其適合訊息很長、或內容需要確實讀到的情境。但它也最容易出現「我明明看過怎麼還算未讀」的抱怨，因為任何載入延遲或 UI 小差異，都可能讓系統認定你沒到最底。
策略 C：以可見範圍判定（Visibility-Based Read）
系統偵測最後一則訊息是否進入可視區域，只要出現過就算已讀。這種做法使用者體感最好，但實作上需要更精細的 UI 事件處理，且在不同裝置與不同列表元件行為下容易有邊界問題。
台灣使用習慣：很多人「快速點進去掃一眼」就退出，對他們來說「進入就清掉未讀」反而更符合期待；但若是客服或工作訊息，通常會希望「看過才算已讀」，避免漏回覆。
Unread vs Total 的最佳實務：如何讓數字「一致且可解釋」
如果你要設計一個可靠的狀態更新系統，重點不是追求完美同步，而是追求一致、可預測、可解釋。以下是常見的最佳實務方向：
1) 明確定義「未讀」：是訊息未讀，還是事件未處理？
在產品文案上區分：「未讀訊息」與「待處理提醒」。如果兩者混在同一個紅點，使用者一定會困惑。
2) 讓未讀的來源單一：以伺服器為準，裝置做快取顯示
本機可以先顯示快取未讀數，提升速度，但一旦伺服器回來的數字不同，要有一致的合併規則，例如以伺服器為主、並保留過渡動畫或提示，避免數字瞬間跳來跳去。
3) 已讀回報要具備「重試」與「冪等」
已讀狀態更新最好設計成可重送、重複送也不會造成錯誤的形式。這樣即使使用者離線、切背景，下一次回到前台仍能補送狀態。
4) 針對推播徽章做一致策略：由伺服器推 badge，或由 App 主動校正
如果 badge 數字不可靠，使用者會更不信任未讀系統。最常見的做法是：每次 App 啟動或回到前台時，主動向伺服器拉最新未讀並設定 badge；同時在收到推播時用「預估值」先加一，待下次同步再校正。
5) 群組聊天室要避免「未讀」與「@提醒」混算
群組可以同時顯示兩種狀態，但請用不同符號，例如未讀用數字、@提醒用小標記，並在設定中讓用戶可選擇是否把 @ 當成未讀的一部分。
排錯指南：當未讀數對不上時，從哪裡查最有效？
如果你是做產品、客服、或工程維運，下面這條排錯路徑通常最快：
- 先確認「狀態來源」：列表顯示未讀是用本機快取還是伺服器回傳？badge 又是誰算的？
- 檢查 read cursor 是否更新：最後已讀訊息 ID 是否有成功寫入伺服器？寫入時間是否合理？
- 檢查同步通道：WebSocket 是否斷線重連？輪詢頻率是否太低？推播是否有喚醒 App？
- 檢查離線與背景限制：省電模式、背景資料限制、通知權限是否影響回報？
- 檢查群組特殊規則：是否把 @、回覆、系統通知算在未讀中？使用者是否開啟了特別過濾？
- 最後再看資料一致性：是否存在重複訊息、時間戳亂序、或訊息刪除導致游標落在不存在的 ID？
只要你能回答「這個未讀數是根據哪個狀態算出來的」，通常就能把問題縮小到某個更新節點，而不是在 UI 上盲目調整。
結語：未讀數不是小功能，它是信任感的核心
對使用者來說，未讀紅點是一種「被提醒」；對產品來說，它是「留存與回訪」的推力；對工程系統來說，它是一套跨裝置、跨網路狀態的同步機制。只要其中一環不一致，使用者就會開始不信任：我到底有沒有漏訊息？我是不是沒回到？為什麼數字一直跳？
回到最初的題目：Unread vs Total Messages，其實不是兩個數字的差別，而是兩套不同目的的計量方式。總數回答「這裡有多少內容」，未讀回答「你還有多少需要注意」。當你把定義講清楚，把狀態更新做成一致、可解釋，未讀紅點就不再是困擾，而會變成一個可靠的導航。