免費線上 UUID 生成器
UUID 對於資料庫主鍵、請求追蹤和分散式系統至關重要。 Dokall 產生符合 RFC 標準的 UUID v4（隨機）和 UUID v7（時間排序）值，您可以一鍵複製。
產生單一 UUID 或批次進行測試。所有生成都在您的瀏覽器本地進行 - 快速、私密且無速率限制。
什麼是 UUID？
UUID（Universally Unique Identifier，通用唯一標識符）是一個 128 位值，格式為五組共 32 個十六進制數字，以連字符分隔：550e8400-e29b-41d4-a716-446655440000。UUID 設計為在空間和時間上都唯一，無需中央機構分配。
UUID 用作數據庫主鍵、API 請求標識符、分佈式系統關聯 ID、檔案名和會話令牌。其關鍵優勢是任何系統都可獨立生成 UUID，且碰撞概率可忽略不計——約需生成 2.71 百京（quintillion）個 UUID，才有 50% 的概率出現一次碰撞。
UUID 版本説明
UUID 有多個版本，各自採用不同的生成策略。
UUID v1 將當前時間戳與機器的 MAC 地址組合。它具有唯一性，且大致按時間排序，但會泄露 MAC 地址和確切創建時間——在某些場景下存在隱私風險。
UUID v4 由密碼學安全的隨機數生成。128 位中有 122 位是隨機的（另有 6 位編碼版本和變體）。這是最常用的版本，因為簡單、私密，且抗衝突能力出色。
UUID v5（以及 v3）使用 SHA-1（v5）或 MD5（v3）對命名空間和名稱進行哈希，生成確定性 UUID。相同的命名空間和名稱總是得到相同的 UUID，適合從自然鍵生成一致的 ID。
UUID v7（RFC 9562，2024）在前 48 位編碼 Unix 時間戳，後接隨機數據。因此 v7 UUID 天然按時間排序，同時仍保持唯一。這對數據庫索引是一大優勢。
UUID v4 與 UUID v7 對比
UUID v4 完全隨機——沒有固有順序。作為帶 B-tree 索引的數據庫主鍵時，隨機 UUID 會使寫入分散到索引各處，導致快取利用率差、I/O 增加，即所謂的索引碎片。
UUID v7 在前 48 位嵌入時間戳，使 ID 隨時間單調遞增。新記錄追加到 B-tree 索引末尾，而不是隨機散落。這大幅提升寫入性能和索引局部性——基準測試中，在插入密集型工作負載下，v7 可比 v4 快 2–5 倍。
UUID v7 還能從 ID 本身提取近似創建時間戳，便於調試、排序和數據生命週期管理。代價是：v7 會暴露記錄創建時間，若創建時間敏感則需留意。
對新項目而言，除非你特別需要 v4 的非順序特性（例如防止對公網 ID 的枚舉攻擊），否則推薦使用 UUID v7。
將 UUID 用作數據庫主鍵
以 UUID 作為主鍵有明顯優勢：可在客户端生成而無需往返數據庫；跨表、跨庫唯一；且不暴露記錄數量或創建順序（v4）。因此非常適合分佈式系統、離線優先應用，以及不宜暴露順序 ID 的 API。
缺點是：UUID 為 16 字節，而整數 ID 通常為 4–8 字節，會增加存儲、內存佔用和連接成本。字符串形式（36 個字符）在基於文本的存儲中更大。隨機 UUID（v4）還會造成上文所述的 B-tree 索引碎片。
實用建議：使用 UUID v7 以避免索引碎片。將 UUID 存為 binary(16) 或原生 UUID 類型（PostgreSQL 有 uuid 類型），而不是 varchar(36)。若數據庫支持，使用 UUID 類型可獲得更好的存儲和比較性能。
UUID 與自增、ULID、Nano ID 對比
自增 ID（SERIAL、IDENTITY）是由數據庫分配的順序整數。緊湊（4–8 字節）、索引快、易讀。缺點：生成需要往返數據庫；會暴露記錄數量和創建順序；且跨表或跨庫不唯一。
UUID 全局唯一，可在任意處生成。缺點：存儲更大（16 字節），且 v4 會造成索引碎片（可由 v7 解決）。
ULID（Universally Unique Lexicographically Sortable Identifier）是 128 位 ID，帶 48 位時間戳前綴，類似 UUID v7，但字符串表示更緊湊（26 個 Crockford Base32 字符，對比 36 個十六進制字符）。ULID 可按時間進行字典序排序。
Nano ID 可生成可配置字母表和長度的隨機字符串 ID。21 字符的 Nano ID 抗衝突能力大致與 UUID v4 相當，但更短。適合需要 URL 友好 ID、又不需要完整 128 位 UUID 格式的場景。
簡單單庫應用可選自增；分佈式系統或 API 可選 UUID v7；在意字符串長度時可選 ULID 或 Nano ID。