設定數量後按「批次產生」一次建立多個 UUID
產生器完全在您的瀏覽器中執行。v4 直接呼叫 crypto.randomUUID()——瀏覽器從作業系統擷取熵值，每個 UUID 提供 122 位元的加密隨機性。v7 讀取 Date.now() 作為 48 位元時間戳記前綴，然後按 RFC 9562 以隨機資料填充剩餘的 74 位元。v1 計算 60 位元的格里曆紀元時間戳記，使用隨機產生的節點 ID（您的真實 MAC 地址不會離開瀏覽器）。v5 透過 SubtleCrypto API 將命名空間和名稱字串通過 SHA-1，對相同輸入每次都產生相同的 UUID。在中階筆電上產生 500 個 v7 UUID 不到 12ms。無伺服器往返，無 API 金鑰。
一般的 UUID 工具只產生一種格式。這個工具提供更多選項。資料庫工程師用批量 v7 UUID 預填測試資料，它們以插入順序到達，在 PostgreSQL 或 MySQL B-tree 索引中不會產生碎片。前端開發者直接匯出為 JavaScript 陣列，省去手動格式化。QA 團隊一次產出 500 個 UUID 用於負載測試 ID 池。v5 讓後端服務產生穩定的識別符，相同的域名在每台機器上都對應到相同的 UUID。也有人用 v4 作為分散式追蹤的關聯 ID 或防碰撞的檔案名稱。所有作業都透過 Web Crypto API 執行——無伺服器呼叫、無速率限制、無需帳號。
新的主鍵用 v7，session token 和關聯 ID 用 v4——這涵蓋了大多數情境。原因是：v7 在前 48 位元放置 Unix 毫秒時間戳記，行會以字典序插入。B-tree 索引保持緊湊，就像自動遞增整數一樣。v4 適用於不需要時間排序的場景。v5 適合內容定址系統，讓相同的域名在每台機器上產生相同的 UUID。新程式碼中可以跳過 v1；它的位元反轉時間戳記使排序查詢變得複雜。 RFC 9562 明確建議 v7 用於對資料庫友善的、時間排序的識別符。將 v4 主鍵替換為 v7 後，可消除高寫入量 PostgreSQL 表中的頁面分裂問題。
所有處理皆在您的瀏覽器中完成，不會傳送任何資料至伺服器。