什麼是 UUID?
UUID(通用唯一識別碼)是一個 128 位元的值,以 36 個字元的字串呈現,例如 550e8400-e29b-41d4-a716-446655440000。其格式與版本語意由 RFC 4122 為 v1 至 v5 定義,並由 RFC 9562 為較新的 v6、v7 與 v8 定義。本工具會產生 v4(純隨機)、v1(時間戳加上隨機節點 ID)以及 v7(Unix 毫秒時間戳前綴加隨機後綴,可依生成時間排序),全部在你的瀏覽器中,透過平台的 Web Crypto API 完成。不會將任何資料傳送至伺服器。
UUID 產生是如何運作的?
不同版本在確定性、可排序性與亂度之間的取捨各不相同。工具會根據您的選擇採用對應演算法:
- v4(隨機)呼叫瀏覽器的
crypto.randomUUID(),回傳 122 位元的密碼學隨機性,並在正確位置設置 6 個固定位元(版本0100與變體10)。碰撞極不可能——大約需要產生 2.71 × 10^18 個 v4 UUID,才能以 50% 的機率撞到一次重複。 - v1(時間戳 + 節點)將 60 位元的格里曆時間戳(自 1582-10-15 起每 100 奈秒一個刻度)放進
time_low/time_mid/time_hi_and_version,將版本半位元組設為0001,選擇帶變體位元的 14 位元時鐘序列,並使用 48 位元隨機節點 ID,且強制將多播位元設為 1(RFC 4122 §4.5 明確允許在沒有硬體 MAC 時使用隨機節點 ID,多播位元將其標示為非 MAC)。 - v7(可排序時間戳)依 RFC 9562 §5.7 排列:48 位元的大端 Unix 毫秒時間戳,接著 4 位元版本
0111,接著 12 位元隨機,接著 2 位元變體10,最後 62 位元隨機。由於時間戳位於最高有效位元,v7 UUID 會依生成順序進行字典序排序——這是其他 UUID 版本未經額外編碼無法達成的特性。 - 所有隨機性皆來自
crypto.getRandomValues(),即瀏覽器的密碼學安全 RNG。v1 與 v7 都加入了同一時鐘刻度內的單調性保護,使同一刻度內的兩次連續呼叫,第二個值仍排在第一個之後——對於跑得比毫秒時鐘還快的批次生成相當重要。 - 生成完成後會執行格式化流程。你可以去除連字符、切換為大寫、用大括號將值包起來(
{…}——Microsoft GUID 慣例),或將原始 16 位元組以 base64 呈現(22 個字元輸出,無填充)。base64 模式會覆寫其他格式選項,因為 base64 本身即是一種獨立表示法。
為什麼使用這個 UUID 產生器?
- 沒有任何資料離開你的瀏覽器。Web Crypto API 在本機執行;頁面在初始文件載入之後不會發出任何網路請求。打開 DevTools、按下產生,網路面板始終保持空白。
- 符合 RFC 的輸出。v4 遵循 RFC 4122 §4.4,v1 遵循 §4.2 與 §4.5,v7 遵循 RFC 9562 §5.7。版本半位元組和變體位元放在標準規定的位置——每一個 UUID 都能通過該版本的標準正規表達式檢驗。
- 可排序的 v7 適合作為資料庫主鍵。在 Postgres、MySQL 或 SQL Server 中把 v7 UUID 作為叢集主鍵,可讓插入持續以追加方式寫入索引——沒有頁面分裂、沒有隨機 I/O——同時仍維持全域唯一。v4 做不到,因為其位元是隨機的。
- 批次生成不受速率限制。一次可產生 1、10、100 或 1,000 個 UUID。沒有配額,也無需註冊——工具在你的分頁中執行,上限是你的 CPU,而非某家廠商的 API 方案。
UUID 有哪些常見應用?
只要系統需要在無需與中央機構協調的情況下取得全域唯一識別碼,UUID 就會派上用場:
- 資料庫主鍵。自動遞增整數會洩漏列數並破壞分片。UUID 在分片之間穩定,在跨區域合併時安全,且(在 v7 下)能讓 B-tree 的插入持續處於熱區、不發生頁面分裂。典型的應用在用戶端產生 UUID,將其放入 INSERT,並且永遠不需要為取得主鍵而往返伺服器。
- 請求關聯 ID。HTTP 中介軟體會在每個傳入請求附上一個 v4 UUID,於每個 span 中記錄,並向下游傳遞(通常作為
X-Request-Id標頭)。當客戶回報問題時,支援工程師貼上該 ID,跨服務與跨時區的完整請求軌跡便清楚呈現,毫無歧義。 - 冪等鍵。付款 API(Stripe、Adyen、Square)接受
Idempotency-Key標頭,使重試的請求不會對客戶重複扣款。用戶端產生的 UUID 保證該鍵對每次邏輯操作都是唯一的,這正是這些 API 所要求的契約。
UUID 範例是什麼樣子?
在 Node.js 或現代瀏覽器中,一行 crypto.randomUUID() 即可回傳一個新的 v4 UUID——例如 3f50b5a8-2c54-4b9c-9c1f-3e5c7e2b8d12。用它作為請求 ID 或冪等鍵即可。當 UUID 要寫入將作為叢集主鍵的資料庫欄位時,應改為產生 v7:相隔一毫秒產生的兩個 v7 值,如 0190a3b0-7d4f-7c9e-8b21-a4d6f0bd9c11 與 0190a3b0-7d50-7f15-9c4e-72b3e0c1d8a4,會依產生順序進行字典序排序。Postgres 的 uuid 型別對兩種版本的儲存方式完全相同——差異出現在寫入索引時:v7 會附加到 B-tree 的最右側,而 v4 的插入則散落各處,迫使產生隨機 I/O。
這款 UUID 產生器只做一件事:把一次點擊變成一個或多個符合 RFC 的識別碼,以你需要的格式輸出,而不會將請求傳送到任何伺服器。選擇版本、選擇數量、選擇格式——產生、複製、繼續工作。