近一段時間，不只我，許多格友都不約而同發現一個令人困擾的現象：在方格子的排程文章列表中，會出現同一篇文章重複顯示的情況。乍看之下，彷彿是系統誤將文章複製了兩次，甚至三次；但當我們點進去檢查，卻會發現一件更弔詭的事——這些看似「重複」的文章，網址 ID 完全相同。(兩性之間的文章出現兩次，確認為同一篇)
這代表什麼？
它不是「兩篇不同 ID 的文章被誤判為同一篇」，而是同一篇文章，在列表層級被重複呈現。這個問題表面上看似是顯示錯誤，但其背後，其實牽涉到一個在程式設計中非常經典、也非常容易被忽略的問題：唯一性（Uniqueness）的錯置。問題不是出在文章，而是出在「怎麼抓文章」
從使用者角度來看，我們直覺會以為系統在「文章層級」出了問題，例如：
- 是否排程被重複建立？
- 是否快取（Cache）未正確更新？
- 是否前端列表渲染錯誤？
但隨著更多格友交叉比對、實際觀察後，逐漸浮現一個高度合理的推測：
問題很可能出在後端抓取排程文章的邏輯設計上。
更精確地說，是「抓排程文章時，系統認定『唯一值』的方式，出了偏差」。
關鍵推測：以「時間區間」當作唯一值
依目前觀察結果推斷，方格子在處理排程文章時，很可能採用了類似以下的設計邏輯：
- 系統每 30 分鐘 為一個排程區間
- 在這個時間區間內，預期只會有「一篇文章」需要顯示
- 因此，在資料抓取或整理列表時，直接以「時間區間」作為唯一識別條件
換句話說，對系統而言：
「7:00、這個區段，只會有一篇排程文章。」
這在「理論假設」上似乎合理，但在「實際使用情境」中，卻完全站不住腳。
真實使用情境：多篇文章同一時間發送
對於創作者來說，這樣的使用行為非常常見：
- 同一天發表 系列文章
- 不同專欄，但設定在 同一時間點發送
- 為了曝光或閱讀習慣，刻意統一在「整點」發文（例如晚上 7:00）
當格友在「同樣是 7:00」這個時間點，排程了 兩篇、甚至三篇不同文章 時，系統實際上會遇到一個它「沒有預期到的狀況」。
結果一：列表中出現「重複文章」
由於系統不是以「文章 ID」作為唯一值，而是以「時間區間」作為分組依據，於是就可能產生以下狀況：
- 同一篇文章被重複撈取
- 或在列表渲染時，被錯誤地顯示多次
- 但實際點進去，全部都指向 同一個文章 ID
這就是為什麼我們會看到：
「看起來是兩篇文章，但實際上是同一篇。」
結果二：後續文章「被吃掉」
更嚴重的，還不只是重複顯示。
若系統在某個 30 分鐘區間內，只保留「第一筆」文章資料，那麼當格友在同一時間排程多篇文章時：
- 第一篇：正常顯示
- 第二篇：不顯示
- 第三篇：完全消失於排程列表
但這些文章其實「都存在」，也都能透過直接網址開啟，只是在列表層級被忽略了。
本質問題：唯一鍵（Unique Key）設計錯誤
從純程式設計的角度來看，這是一個非常典型的錯誤：
不該作為唯一值的欄位，被拿來當唯一值使用。
在任何內容管理系統（CMS）中，合理的唯一識別，應該至少包含：
- 文章 ID（Primary Key）
- 或（文章 ID + 排程時間）
而不是：
- 單純以「時間區間」當作唯一判斷條件
時間是可能重複的，尤其是在創作者高度活躍的平台上。
為什麼這個問題「不容易被發現」？
原因其實很現實：
- 一般使用者很少同一時間排程多篇文章
- 問題只會在「特定使用行為」下才會浮現
- 點進文章後又是正常的，讓人誤以為是自己眼花
直到越來越多格友同時遇到、彼此討論，這個模式才逐漸清楚浮現。
結語：這不是小 Bug，而是設計假設的問題
這類問題，並不是程式寫錯一行那麼簡單，而是：
一開始對「使用者行為」的假設，與真實世界不一致。
只要系統仍然假設「每個時間區間只會有一篇文章」，那麼這個問題就會一直存在。
對創作者來說，我們能做的或許有限，但至少現在——
我們終於知道問題不是出在自己身上，也不是文章出錯，而是唯一性被錯置了。
而對平台而言，真正需要修正的，並不是顯示層，而是資料結構中「誰才是真正唯一」的那個核心判斷。
如果你願意，我也可以幫你再寫一篇：
- 🔧「給非工程師看的版本（白話解釋）」
- 📣「寫給平台工程團隊的建議說明文」
- 🧠「從產品設計角度反思排程系統」
只要跟我說一聲即可。
