是的。v4 和 v7 都用 crypto.getRandomValues 安全隨機 API。v4 有 122 位元熵, v7 有 74。

為什麼 v7 適合資料庫鍵?

v7 UUID 按建立時間排序, 插入總在 B-tree 索引末尾而非隨機位置。避免頁分裂, 大幅提升寫吞吐。

兩個 UUID 會碰撞嗎?

理論上可以。v4 需生成 ~10¹⁸ 才有 50% 碰撞風險。v7 同毫秒內為 2⁷⁴ — 實際上不可能。

是。GUID 是 Microsoft 對 UUID 的稱呼。同樣格式, 同樣唯一性保證。

8-4-4-4-12 hex 字元用連字元分隔。共 32 hex 字元 + 4 連字元 = 36 字元。RFC 約定小寫。

v1 包含 MAC 地址, 隱私洩漏。需要時間排序 ID 而不暴露硬體識別符號就用 v7。

本工具不直接支援。把 UUID 16 位元組編碼為 URL Safe Base64 得 22 字元 ID, 適合短 URL。

不會。生成全部在本地。

v4 / v7 切換, 一鍵生成大量 UUID。完全隨機用 v4, 資料庫主鍵等需要時間排序場景用 v7。

UUID v4 是純隨機 — 122 個隨機位元加 2 個版本/變體位元, 給出約 5.3 × 10³⁶ 種可能。兩個碰撞基本不可能。不需要排序的場合用 v4, 例如 API 請求 ID 或匿名使用者標識。

UUID v7 (RFC 9562, 2024 年釋出) 以 48 位元 Unix 毫秒時間戳開頭, 後跟 74 位元隨機。按字典序排序就是建立順序 — 對資料庫效能影響巨大: 主鍵按時間排序意味著插入總在 B-tree 末尾, 沒有隨機頁分裂。新資料庫主鍵用 v7。

v4 與 v7 都用 crypto.getRandomValues — 瀏覽器加密學安全的隨機源, HTTPS 與密碼管理器使用的是同一原語。v4 把 122 位元填隨機。v7 按 RFC 拆分 48 位元時間戳 + 74 位元隨機加版本/變體標記。

生成在瀏覽器內進行。UUID 不儲存不傳輸。生成 100 個 v4 間碰撞的機率天文數字小 — 遠低於 CPU 中宇宙射線翻轉位元的機率。

v4 UUID 作為資料庫主鍵效能不及自增整數, 因為隨機值導致插入時 B-tree 頁分裂。v7 解決此問題 — 想要 UUID 優勢又無索引痛點的話用 v7。

對使用者暴露 UUID 時, 可猜測性很重要。v4 有 122 位元熵不可猜測。v7 洩漏建立時間, 多數場景沒問題但若建立時間敏感則不適。

UUID 含連字元共 36 字元 (32 hex + 4 hyphens)。二進位制 16 位元組, 文本 36 位元組。極高基數列考慮用 BINARY (16) 或原生 UUID 型別而非 VARCHAR(36)。