什麼是 UUID？

UUID（Universally Unique Identifier，通用唯一識別碼）是 128-bit 的識別碼，用 32 個 16 進位字元加 4 個連字號表示成 8-4-4-4-12 格式，例如 550e8400-e29b-41d4-a716-446655440000。原始規範 1997 年由 OSF DCE 提出，IETF RFC 4122 標準化。2024 年新版 RFC 9562 把 v6 / v7 / v8 納入官方規範。

128-bit 的空間是 2^128 ≈ 3.4 × 10^38，即使每秒產生 10 億個，連續產 10 兆年的碰撞機率仍小到可以忽略。所以不必中央伺服器發號，各個分散式節點本地產生也不會撞 ID。

UUID 各版本一覽

v1：時間 + MAC 位址。會洩漏產生主機的網卡資訊，現代少用
v3 / v5：用名稱 + namespace 算 hash（v3 MD5、v5 SHA-1）。相同輸入永遠相同 UUID，適合「以網址產生穩定 ID」
v4：純亂數。最常見、相容性最好
v6 / v7：時間排序版。前 48 bit 是時間戳，可被 B-tree 索引高效排序
v8：自訂版。RFC 9562 預留給「廠商自己定義內容」

v4 vs v7 怎麼選？

v4（隨機）：完全亂數，無時間順序。最常見、相容性最好（所有資料庫都支援）。不需排序時用這個。
v7（時間排序）：前 48 bit 是 Unix ms 時間戳。做為資料庫主鍵時索引效能最佳（插入順序與儲存順序一致，不會像 v4 那樣造成 B-tree split）。RFC 9562 標準，後端建議首選。

使用情境

資料庫主鍵（PostgreSQL UUID 型別、MongoDB ObjectId 替代）
API request ID / 分散式追蹤 correlation ID
session token、CSRF token（短期用）

UUID vs Auto-increment ID

Auto-increment（1, 2, 3...）：小整數、儲存省、索引極快、人類好讀。劣：洩漏「我們有幾筆資料」、跨服務難整合、必須中央發號
UUID：分散式產生、不洩漏總數、跨系統整合容易。劣：佔 16 bytes（vs 整數的 4-8），v4 碰索引可能 fragment（v7 解決）
實務：對外的 public ID 用 UUID v7，內部報表 join 鍵用整數，可兼顧兩邊

常見問題

UUID 真的不會撞嗎？

理論上會，實際上幾乎不會。要在 v4 中撞兩個 UUID 需要產生約 2^61 個（生日攻擊上限）。即使每秒產生 10 億個，要撞一次也要 73 年。對絕大多數應用，視為「永不碰撞」是合理假設。

UUID 安全嗎？能當 session token 嗎？

v4 / v7 用 crypto.getRandomValues() 產生時，隨機性是密碼學等級，可作短期 session token。但 UUID 結構公開（有 version、variant bits），實際亂數位元數是 122 而非 128。長期使用，建議用更長的 token（256-bit 或更多）。

為什麼 UUID 中間有「4」？

那是版本標記位元。第 13 個字元固定是版本號（v4 永遠是 4、v7 是 7 等）。第 17 個字元也固定（variant，通常是 8/9/a/b）。剩下的 122 個 bit 才是真正的亂數。

UUID 跟 ULID / NanoID 差在哪？

ULID 也是時間排序的 128-bit ID，但用 Base32 編碼成 26 字，比 UUID 的 36 字短。NanoID 是更短的隨機字串（預設 21 字、URL-safe）。三者各有粉絲，不過 RFC 9562 把 UUID v7 標準化後，ULID 的優勢縮小了。

隱私說明

本工具用瀏覽器原生 crypto.randomUUID() 與 crypto.getRandomValues()產生，亂數品質為密碼學等級。所有 UUID 在你的瀏覽器內產生，不會傳到任何伺服器。

UUID 產生器