「這個 ID，絕對不會跟別人重複嗎？」

在系統中處理資料時，不可避免地會面臨「ID（識別碼）」的設計問題。
「使用者 ID，用簡單的連號可以嗎？」、「當資料量增加時，萬一跟另一台伺服器的資料重複了該怎麼辦……」

UUID (Universally Unique Identifier) 基礎知識：種類與選用指南

能消除這類不安，且在任何分散式環境中無需中央管理即可即時產出「世界上唯一一個 ID」的 MAGIC，就是 UUID (Universally Unique Identifier)。

UUID：注入 128 位元中的「奇蹟」

UUID 擁有 128 位元這一龐大的資訊量。
其組合的數量多到驚人，據說即使全人類在一生當中，每秒鐘持續產生 10 億個 UUID，發生重複的機率也趨近於零。

正因為有這份壓倒性的「安心感」，我們才能放心地在資料庫或微服務 (Microservices) 之間共享 ID。

該選哪一個？UUID 版本挑選的關鍵

雖然 UUID 有好幾種版本，但現代開發者主要只需記住這三種：

  • Version 4：完全隨機
    • 特性：完全隨機，無法預測。
    • 適用場景：Session ID、臨時檔案名稱等「總之不希望重複且不希望被猜到」的用途。
  • Version 7：結合時間戳記的可排序 UUID
    • 特性：字串開頭包含時間戳記。
    • 適用場景：資料庫主鍵 (Primary Key)。由於它是按產出順序排列的，因此能在不犧牲資料庫搜尋效率（索引性能）的前提下，享受 UUID 的優點。這是 2024 年才標準化，目前最受矚目的選擇。
  • Version 1：機器的證跡（MAC 位址）
    • 特性：能看出是由哪台機器、在什麼時間點產出的。
    • 適用場景：具備歷史背景的系統，或是需要追蹤特定設備的情況。

若感到迷惑，何不先動手試試？

「UUID 長什麼樣子？」、「我想一次產出 100 個 v4 UUID」。
這種時候，請試試本站的 UUID 生成工具。

每點選一次按鈕，瞬間就會誕生一組全新的 UUID。凝視著那組無機質卻又可靠的字串，或許會讓廣大的分散式系統世界，感覺變得親近了一些。

結語

UUID 是將各自獨立運行的系統連結在一起的「紐帶」。
配合用途選擇最合適的版本，從對 ID 重複的擔憂中解脫吧。將唯一性的保證交給工具，而您可以將精力投入到更有價值的邏輯實作中。

常見問題

UUID v4 真的是隨機的嗎？

是的。v4 的 128 位元中有 122 位元來自隨機值，其餘 6 位元用於標示版本與變體。實務上碰撞的機率低到可以忽略，但前提是使用了密碼學安全的亂數產生器。若以 Math.random() 之類的弱亂數自行實作，隨機性會下降，請使用各語言標準函式庫提供的 UUID 產生器。

應該把既有的 v4 全部遷移到 v7 嗎？

不需要。v7 的優點在於「依時間排序」，主要是為了改善資料庫索引的局部性。若現有的 v4 沒有造成效能問題，就沒有理由承擔遷移的風險。新建立的資料表若以 UUID 當主鍵且寫入量大，則值得從一開始就採用 v7。

兩台機器有可能產生相同的 v4 嗎？

理論上不是零，但機率極低。即使每秒產生十億個 UUID 並持續數十年，發生一次碰撞的機率仍遠低於實務上需要擔心的水準。真正需要注意的反而是實作缺陷——例如亂數種子固定、或在容器中複製了相同的初始狀態。

什麼是 nil UUID？

指所有位元都為 0 的 00000000-0000-0000-0000-000000000000。它常被當作「尚未設定」的預設值使用，但要注意：資料庫的 NOT NULL 欄位會接受它，因此無法用非空約束來偵測「忘記設定」的情況。

如何驗證 UUID 的格式？

以正規表示式檢查 8-4-4-4-12 的十六進位格式即可，但若要連版本也一併確認，需要檢查第 13 個字元（版本）與第 17 個字元（變體）。實際貼上字串確認結構時，可以使用 UUID 產生器，也能一併確認產生結果的格式。