UUID生成器：線上生成UUID v4唯一識別符號（可批次，2026）

下面這個uuid生成器工具，純瀏覽器本地執行，即時出結果不上傳資料。往下有原理和使用說明。

UUID 是什麼，這個工具幫你解決什麼

UUID 是一串 128 位的唯一識別符號，不依賴中央資料庫分配，就能讓分散式系統各自生成、幾乎絕不重複的 ID。上面的工具在你瀏覽器本地生成標準 UUID v4，支援一次批次出幾十上百條、一鍵複製或匯出，全程不聯網、不上傳伺服器，做測試資料、填資料庫主鍵、給物件命名都能直接拿去用。

原理：128 位裡，122 位是純隨機

UUID v4 的做法很直接——除去用來標記「版本」和「變體」的 6 個固定位元，剩下 122 位全部由密碼學隨機數填充。它不看時間、不看機器網絡卡，純靠隨機性來避免碰撞。標準寫法是 8-4-4-12 的十六進位制分組，比如 f47ac10b-58cc-4372-a567-0e02b2c3d479：其中第 13 位固定是 4（版本號），第 17 位只會是 8、9、a、b 之一（變體位），這也是肉眼分辨一條 UUID 是不是 v4 的最快辦法。規則出自 IETF 2024 年釋出的 RFC 9562，它已取代沿用二十多年的舊標準 RFC 4122。

什麼場景該用它

凡是「多個節點各自造 ID，又不能撞車」的地方，UUID 都是預設選擇：微服務裡給每個請求打鏈路追蹤 ID、前端在沒拿到後端主鍵前先佔位、訊息佇列做冪等去重、檔案與物件儲存的命名、資料庫合併時避免自增主鍵衝突。它的最大好處是離線也能生成——不用先問資料庫要一個號，這在移動端弱網、邊緣計算、多主寫入場景裡尤其關鍵。反過來，如果你只是給單庫單表做主鍵、又特別在意索引效能，那 v4 的「完全無序」會拖慢 B+ 樹寫入，這時更該看下面表格裡的 v7。

選版本：v1、v4、v7 怎麼挑

RFC 9562 新增的 v7 是這兩年的熱點：它把毫秒級時間戳放在高位，天然按生成順序遞增，既保留了隨機性防碰撞，又解決了 v4 插入亂序導致的資料庫頁分裂問題——想拿 UUID 當 MySQL/PostgreSQL 主鍵，優先考慮 v7 而不是 v4。

常見疑問：真的不會重複嗎

要真正安全，關鍵是隨機源必須是加密級的（CSPRNG）。本工具呼叫瀏覽器原生的 crypto.randomUUID() / crypto.getRandomValues() 介面取隨機數，而非 Math.random()，從源頭保證生成質量。

相關閱讀：隨機數生成器；時間戳轉換；進位制轉換。