上半是可以直接操作的原型，UI 與操作邏輯看這個；下半是資料欄位、行為規則與邊界情況。 看到哪裡有問題，把那段話反白留言就好——我會知道你在講哪一段。
下一個版本要加通知中心。與其寫三千字讓你自己想像，我直接做一個給你按，再把規格附在下面。
這一頁就是要交給你的文件：原型定 UI 與操作、規格定資料與規則、最後四題是我需要你判斷的技術決定。
左邊切換情境，右邊直接操作。UI 與操作邏輯以這個原型為準， 下面的規格是它背後的資料與規則。
原型講的是「長什麼樣、怎麼動」，這一段講的是「資料怎麼存、規則怎麼判」。 有疑問一樣反白留言就好。
| 欄位 | 型別 | 說明 | 備註 |
|---|---|---|---|
| id | string | 通知唯一碼 | UUID，前端不解析內容 |
| user_id | string | 收件人 | 一則通知只對應一個人；多人要各建一筆 |
| type | enum | 訂單 / 審批 / 系統 | 決定列表上的標籤顏色與篩選 |
| title | string | 顯示文字 | 最長 60 字，超過在後端截斷並補「…」 |
| target_url | string? | 點擊跳轉目標 | 可為空。空的時候點了只標已讀 |
| is_read | boolean | 已讀狀態 | 預設 false |
| created_at | datetime | 產生時間 | 列表用這個排序，新的在上 |
| read_at | datetime? | 讀取時間 | 標已讀時寫入，之後可用來做清理 |
| 情況 | 預期行為 | 對照 |
|---|---|---|
| 完全沒有通知 | 顯示空狀態：「目前沒有通知 / 有新的訂單或審批就會出現在這裡」 | 原型左邊第 4 個情境 |
| 某個類型沒有通知 | 顯示「這個類型沒有通知 / 換個類型看看」，紅點不變 | 原型切篩選就看得到 |
| 未讀超過 99 | 紅點顯示上限值，實際數字不顯示 | 見 Q1，原型第 2 個情境 |
| target_url 為空 | 點了只標已讀，畫面留在原地 | 原型現在就是這個行為 |
| 同一則在兩台裝置同時點 | 以先到的為準，第二次呼叫回 200 不報錯 | 冪等，不要跳錯誤訊息 |
| 通知超過 30 天 | 待確認 | 見 Q2，原型第 5 個情境 |
| 使用者被停用 | 不再產生新通知，既有的保留 | 不影響現有資料 |
旺季一天可能上百則。這個決定紅點的呈現與後端要不要算精確數字。
這決定資料表會長多大，以及要不要排清理排程。
這題影響架構，我先講我要的體驗，可行性你評估。
我原型裡是「點了就標已讀、留在原地」，但實際上可能要跳轉。