UUID 產生器

格式选项

生成数量

1 个

免費線上 UUID/GUID/ULID/NanoID 產生器，支援 5 種唯一 ID 格式、批次最多 100 條、格式自訂和 UUID 驗證辨識，打開即用適合資料庫主鍵和測試造數。

相關推薦

Lorem Ipsum 產生器

密碼產生器

JWT 工具

MD5 雜湊

十六進位轉換器

SHA-256 雜湊

什麼是 UUID？

UUID（Universally Unique Identifier，通用唯一識別碼）是一種 128 位元的識別碼標準，由開放軟體基金會（OSF）標準化，定義在 RFC 4122 中。它的目的是讓分散式系統中的所有元素都能有唯一的識別資訊，而不需要透過中央控制端來做 ID 的指定。

一個標準的 UUID 形如 `550e8400-e29b-41d4-a716-446655440000`，由 32 個十六進位數字組成，以連字號分成 5 段（8-4-4-4-12）。理論上 UUID v4 的碰撞機率約為 1/10^36，即每秒產生 10 億個 UUID，持續約 800 年才會有 50% 機率發生一次碰撞，實際應用中可以認為是唯一的。

UUID 被廣泛應用於資料庫主鍵、分散式追蹤 ID、請求 Request-ID、日誌 Trace-ID、檔案唯一命名、測試資料 ID、工作階段識別等場景，幾乎所有主流程式語言都內建了 UUID 產生函式庫。

適用場景

  • 資料庫設計時產生 UUID v4 作為資料表記錄主鍵，避免自增 ID 洩漏資料量
  • 分散式系統或微服務架構中使用 ULID 作為可排序的全域唯一請求追蹤 ID
  • API 開發與串接時批次產生一批 UUID 作為測試資料和模擬訂單編號/使用者 ID
  • 前端 URL 短鏈或分享連結中使用 NanoID 替代 UUID，更短更美觀無需 URL 編碼
  • 使用 UUID v5 基於固定命名空間產生確定性 ID，確保相同輸入始終得到相同輸出
  • 除錯日誌或第三方文件中遇到不確定格式的 ID 時，使用驗證功能辨識 ID 類型和版本

使用方法

  1. 在上方卡片中選擇需要產生的 ID 類型：UUID v4（推薦）、v1、v5、ULID 或 NanoID
  2. 如選擇 UUID v5，需輸入命名用的字串；其他 ID 可直接設定格式選項
  3. 根據需要切換大小寫和連字號開關，透過快捷按鈕或滑桿設定批次產生數量（1-100）
  4. 點擊產生按鈕後檢視結果列表，可逐條複製、一鍵複製全部或匯出 TXT/JSON 檔案
  5. 如需驗證已有 ID，切換到「驗證」分頁貼上 ID 字串即可得到類型和版本資訊

功能特點

  • 五種 ID 一頁涵蓋：同時支援 UUID v1（時間戳記）、v4（隨機）、v5（命名空間）、ULID（可排序）、NanoID（URL 安全），一個工具滿足不同技術堆疊需求
  • UUID 驗證辨識：切換到驗證分頁，貼上任意 ID 即可辨識是 UUID 哪個版本，還是 ULID/NanoID 格式，除錯時快速排查問題
  • 批次產生最高 100 條：支援 1-100 條任意數量批次產生，測試造數不再手動一條一條複製
  • 格式靈活切換：UUID 支援大小寫和連字號開關，適配資料庫、URL、設定檔等不同場景的格式要求
  • 匯出與歷史記錄：支援一鍵複製全部、匯出 TXT/JSON 檔案，產生歷史本機儲存可隨時恢復，批次操作更有效率
  • 純前端安全隨機：使用瀏覽器 crypto API 產生加密級隨機數，ID 不上傳伺服器，斷網可用

程式碼範例

JavaScript 產生 UUID v4

javascript

現代瀏覽器和 Node.js 14.17+ 內建了 Web Crypto API，可以直接產生 UUID v4，無需第三方函式庫。

// 現代瀏覽器 / Node.js 19+
const id = crypto.randomUUID();
console.log(id); // "550e8400-e29b-41d4-a716-446655440000"

// Node.js 14.17 - 18.x
const crypto = require('crypto');
const id = crypto.randomUUID();

Python 批次產生 UUID

python

使用 Python 標準函式庫 uuid 模組批次產生多個 UUID v4，適合測試資料準備。

import uuid

# 產生單個UUID
uid = uuid.uuid4()
print(uid)

# 批次產生10個
for _ in range(10):
    print(uuid.uuid4())

# 產生無連字號的大寫UUID
print(uuid.uuid4().hex.upper())

Shell 命令列產生 UUID

bash

在 Linux/macOS 終端機中快速產生 UUID，適合 shell 腳本中使用。

# Linux
uuidgen

# macOS
uuidgen | tr 'A-Z' 'a-z'

# 直接從系統隨機檔案讀取（最原始方式）
cat /proc/sys/kernel/random/uuid

唯一 ID 該選哪種方案？

UUID 不是唯一選擇，資料庫自動遞增 ID 和 Snowflake 也是主流主鍵方案。先看「資料規模、是否需要全域唯一、是否需要按時間排序」再選具體方案，能少走很多彎路。

UUID v1 / v4 / v5 / ULID / NanoID：該選哪個？

5 種 ID 在資料規模、排序性、字元長度上各有取捨。先看「用在哪裡 + 是否需要排序 + URL 是否直接用」做決策，比按數字本身更靠譜。

方案推薦場景排序性長度推薦度
UUID v1需要按時間排序、能接受洩漏 MAC 位址和產生時間的內部系統按時間有序36 字元⚠️ 一般不推薦（洩漏隱私）
UUID v4資料庫主鍵、通用識別、絕大多數業務場景無序（隨機）36 字元✅ 通用首選
UUID v5需要確定性輸出（相同輸入 → 相同 UUID）的場景無序36 字元✅ 命名空間固定時推薦
ULID分散式系統主鍵、日誌追蹤、需要按時間排序的索引按時間有序（前 48 bit 是毫秒時間戳記）26 字元✅ 分散式系統首選
NanoIDURL 短鏈、Cookie 識別、前端 JS 引用無序（隨機）21 字元（預設）✅ 短 ID 場景首選

UUID vs 資料庫自動遞增 ID vs Snowflake ID：主鍵方案怎麼選？

這三種是後端主鍵最常見的方案，決定了系統的擴展能力、並發安全和效能特徵。按「資料規模 / 是否有全域唯一要求 / 是否需要可讀」決策能避免後期架構調整。

維度UUID資料庫自動遞增 IDSnowflake
全域唯一✅ 是（理論上）❌ 否（分庫分表會重複）✅ 是（資料中心+機器 ID 保證）
資料量洩漏✅ 不洩漏❌ 直接洩漏（遞增 1, 2, 3 暴露真實資料量）⚠️ 時間位洩漏產生時間（不直接洩漏總量）
排序性❌ 無序（ULID 除外）✅ 單調遞增（B-Tree 友善）✅ 趨勢遞增（同一毫秒內有序）
分庫分表✅ 天然支援❌ 需引入發號器或改造✅ 通過 worker ID 區分
儲存成本⚠️ 高（BINARY(16) 16 位元組）✅ 低（BIGINT 8 位元組）✅ 低（BIGINT 8 位元組）
適合場景多服務/分散式主鍵、對外識別、資料量敏感業務單體應用、後台管理系統、不需要全域唯一高並發 IM、訂單編號、訊息 ID（需自行實作）

最佳实践

生產資料庫主鍵優先選 UUID v4 或 ULID，避免 v1

UUID v1 的後 48 bit 是 MAC 位址，前 48 bit 是 100ns 精度時間戳記——**這兩個欄位可被還原成機器指紋和產生時間**。v1 在 RFC 4122 中已明確「only when backward compatibility is needed」（僅在需要向後相容時使用）。生產環境應優先選 v4（隨機）或 ULID（可排序），v1 僅在做除錯、需要追溯產生機器時偶爾使用。**絕對不要**用 v1 作為對外暴露的使用者 ID、裝置 ID 或訂單編號。

UUID v1、v4、v5 應該怎麼選？

UUID 長度 128 bit ≠ 熵值：v4 實際只有 122 bit

UUID v4 雖然有 128 bit 總長，但**前 4 bit 是版本號（固定為 0100），後 2 bit 是變體號（固定為 10）**，真正隨機的只有 122 bit。這是 RFC 4122 規定的格式約束，**任何聲稱「128 bit 全隨機」的 UUID v4 函式庫都是錯誤實作**。另外 v4 的後 64 bit 中第 7 個位元組的高 2 bit 也是變體欄位，實際熵更低。設計系統時按 122 bit 算安全性（而非 128 bit），避免低估碰撞風險。

RFC 4122 - UUID 規範

儲存 UUID 務必用 BINARY(16) 列而不是 VARCHAR(36)

UUID v4 字串 `550e8400-e29b-41d4-a716-446655440000` 看起來緊湊，實際 VARCHAR(36) 存 36 位元組+ 2 位元組長度 = 38 位元組，**比 BINARY(16) 多 2.4 倍儲存空間**。MySQL/PostgreSQL/MSSQL 都內建 UUID 函式支援直接寫 BINARY(16)，索引大小也減半。表超過 1 億行時 VARCHAR(36) 主鍵索引會讓 B-Tree 高度多 1-2 層，**查詢效能下降 30-50%**。前端展示時再轉字串，業務層一律 BINARY(16) 傳輸。

UUID / ULID / NanoID 對比表

URL 場景用 NanoID 或無連字號 UUID，避開 URL 編碼

UUID v4 字元集是 `[0-9a-f-]`，**連字號 - 在 URL path 中需要兩次 URL 編碼**（先跳脫為 %2D，再跳脫為 %252D），非常難看。兩種解決方案：**（1）URL 場景直接用 NanoID**（預設 21 字元 URL 安全）；**（2）UUID v4 + 關閉連字號**輸出 32 位元純 hex，作為 URL path segment 無需編碼。Cookie 場景同樣優先 NanoID（A-Za-z0-9_-）或無連字號 UUID，避開 `+` `/` `=` 字元（Base64 字元集）。

產生的 UUID 可以去掉連字號或轉大寫嗎？

批次產生後務必去重，產生器 bug 可能造成重複

UUID v4 碰撞機率約 1/10^36，理論上無需去重——**但工程上不要相信理論**。Linux 核心 RNG 故障、Node.js 早期版本的 `crypto.randomUUID` 實作 bug、Cloud VM 啟動時熵源不足等真實事故都導致過批次產生的 UUID 包含重複值。**生產環境中批次產生 10w+ UUID 後必須用 `SELECT id, COUNT(*) FROM t GROUP BY id HAVING COUNT(*) > 1` 做一次去重校驗**，發現問題立即回滾產生器版本。這是資料遷移、批次匯入場景下用血的教訓換來的最佳實務。

可以一次批次產生多條 UUID 嗎？

常見問題

UUID 和 GUID 有什麼區別？

UUID（Universally Unique Identifier）和 GUID（Globally Unique Identifier）本質上是同一個東西，只是稱呼不同：UUID 是 IETF 標準（RFC 4122）的正式名稱，GUID 是微軟在 Windows 生態系中的習慣叫法。兩者的格式完全一致，都是形如 `550e8400-e29b-41d4-a716-446655440000` 的 128 位元識別碼。本工具產生的標準 UUID 可以直接用於任何需要 GUID 的場景。

UUID v1、v4、v5 應該怎麼選？

UUID v1 基於時間戳記和 MAC 位址產生，按時間有序可追溯，但可能洩漏 MAC 位址；UUID v4 完全基於隨機數產生，是最常用、最安全的選擇，適合絕大多數主鍵和識別場景；UUID v5 是基於命名空間的雜湊版本（SHA-1），相同命名空間+相同名稱始終產生相同 UUID，適合需要確定性輸出的場景。一般開發中預設選 UUID v4 即可。

ULID 和 NanoID 相比 UUID v4 有什麼優勢？

ULID（26 字元）比 UUID（36 字元含連字號）更短，按時間排序，適合資料庫索引和日誌追蹤；NanoID（預設 21 字元）更短更快，使用 URL 安全字元，URL 和 Cookie 中無需跳脫，體積比 UUID 小 30%。三者碰撞機率都極低，但分散式系統中 ULID 的可排序性更有優勢，NanoID 在前端/URL 場景下更友好。

可以一次批次產生多條 UUID 嗎？

可以。本工具支援 1 到 100 條批次產生，點擊數量按鈕或拖曳滑桿設定數量後一鍵產生，適合測試造數、批次匯入和腳本準備唯一 ID。產生後支援一鍵複製全部結果，也可匯出為 TXT 文字或 JSON 檔案。

批次產生操作說明

可以驗證一個字串是不是合法的 UUID 嗎？

可以。切換到「驗證」分頁，輸入任意字串，工具會自動辨識並驗證：標準 UUID（v1/v3/v4/v5）會告知具體版本號，還支援辨識 ULID（26 位元 Crockford Base32 格式）和 NanoID（21 位元 URL 安全字元）格式，開發除錯中快速排查 ID 格式問題非常方便。

線上產生 UUID 會洩漏到伺服器嗎？安全嗎？

完全安全。本工具所有 ID 產生和驗證都在你本機瀏覽器中透過 JavaScript 完成，使用 crypto.getRandomValues() 加密安全隨機數，不會向任何伺服器發送你產生的 ID，也不會記錄產生歷史到雲端。即使斷網也可以正常使用，適合在企業內網和敏感專案中使用。

產生的 UUID 可以去掉連字號或轉大寫嗎？

可以。對於 UUID v1/v4/v5，工具提供兩個開關：「大寫」可切換輸出大小寫，「連字號」可去掉中間的橫槓（適合在 URL、設定檔或某些資料庫中使用無連字號格式）。ULID 和 NanoID 預設無連字號，也支援大小寫切換。

為什麼推薦用線上工具而不是命令列產生 UUID？

命令列（如 Linux 的 uuidgen、Python 的 uuid 模組）需要開發環境支援，線上工具打開即用，無需安裝任何軟體。此外本工具還整合了 UUID 版本辨識、批次匯出、歷史記錄等加值功能，在跨裝置（如幫非技術同事產生 ID）或臨時需要時更方便。

術語表

UUID
通用唯一識別碼（Universally Unique Identifier），128 位元長度，RFC 4122 標準，常用版本有 v1（時間戳記+MAC）、v4（隨機）、v5（SHA-1 雜湊）。
GUID
全域唯一識別碼（Globally Unique Identifier），微軟對 UUID 的稱呼，兩者格式和用途完全相同。
ULID
按字典序可排序的唯一識別碼（Universally Unique Lexicographically Sortable Identifier），26 個字元，使用 Crockford Base32 編碼，前 48 位元為時間戳記，可按建立時間排序。
NanoID
一種輕量級的唯一 ID 產生方案，預設 21 個 URL 安全字元（A-Za-z0-9_-），比 UUID 更短、更快，適合前端和 URL 場景使用。
UUID v1
基於時間戳記和 MAC 位址的 UUID 版本，按時間可排序，但可能洩漏 MAC 位址和產生時間，安全性低於 v4。
UUID v4
完全基於隨機數產生的 UUID 版本，使用最廣，碰撞機率極低，是開發中的預設選擇。
UUID v5
基於 SHA-1 雜湊的命名空間 UUID 版本，相同命名空間+相同名稱輸入會產生相同的 UUID 輸出，適合確定性場景。
碰撞機率
兩個隨機產生的 ID 恰好相同的機率。UUID v4 的碰撞機率約為 170 億分之一兆，可以在實際工程中忽略。
Crockford Base32
Douglas Crockford 設計的 Base32 編碼，使用排除了 I/L/O/U 的大寫字母和數字，避免易混淆字元，ULID 使用此編碼。

UUID / ULID / NanoID 對比表

特性UUID v4ULIDNanoID
長度36 字元（含連字號）/ 32 字元（無連字號）26 字元預設 21 字元
字元集十六進位（0-9a-f）Crockford Base32（32 個字元）URL 安全（64 個字元）
排序性無序（隨機）按時間有序無序（隨機）
URL 安全需跳脫（含連字號和字母數字）基本安全（大寫字母+數字）完全 URL 安全
產生速度快快比 UUID 快約 60%
碰撞機率1/10^361/10^361/10^34（21 位元時）
典型場景資料庫主鍵、通用 ID分散式系統、日誌追蹤短鏈 URL、前端識別、Cookie

各語言產生 UUID 的常用方法

語言程式碼
JavaScriptcrypto.randomUUID() // 現代瀏覽器/Node.js 19+
Pythonimport uuid; uuid.uuid4()
JavaUUID.randomUUID()
Gogithub.com/google/uuid; uuid.New()
Bash/Linuxuuidgen 或 cat /proc/sys/kernel/random/uuid

Authoritative References