ID Generator 唯一識別碼產生器 | UUID v7 / ULID / Nano ID / CUID2

ID 格式比較

格式	可排序	URL 安全	長度	亂度	特點
UUID v4	❌	✅	36 (32+4)	⭐⭐⭐⭐⭐	純隨機，最廣泛使用
UUID v7	✅	✅	36 (32+4)	⭐⭐⭐⭐⭐	時間有序，適合 DB 索引
ULID	✅	✅	26	⭐⭐⭐⭐	Crockford Base32，可排序
Nano ID	❌	✅	可變 (預設 21)	⭐⭐⭐⭐⭐	輕量高效，64 字元字母表
CUID2	❌	✅	約 24	⭐⭐⭐⭐⭐	水平擴展安全，防碰撞
Short ID	❌	✅	可變 (自訂)	⭐⭐⭐	簡短靈活，自訂字母表

碰撞機率估算

根據每天產生的 ID 數量與使用時間，估算 ID 碰撞的機率。

每天產生 ID 數量

使用多久（年）

ID 格式

≈ 0%

Estimated Collision Probability

尚未計算

常見問題

UUID、ULID、Nano ID 有什麼差別？

UUID (v4) 是 128 位元的通用唯一識別碼，完全隨機產生，廣泛用於資料庫主鍵與分散式系統。但由於純隨機特性，不適合做 B-tree 索引 (會導致頁面分裂)。

ULID 同樣是 128 位元，但前 48 位元是時間戳，後 80 位元是亂數，因此具備「可排序」特性，且使用 Crockford Base32 編碼，長度僅 26 字元。

Nano ID 使用 64 字元字母表 (A-Za-z0-9_-)，預設長度 21 字元即可達到與 UUID v4 相近的亂度。體積小、速度快，常使用在短網址、檔案命名等場景。

什麼時候該用 UUID v7 而不是 UUID v4？

UUID v7 的核心優勢是「時間有序」。v7 的前 48 位元為 Unix 毫秒時間戳，這使得產生的 ID 天然具備單調遞增特性。

如果你的資料庫使用 B-tree 或 LSM-Tree 作為索引結構（如 PostgreSQL、MySQL、SQLite），使用 UUID v7 能大幅減少索引頁面分裂與隨機寫入的開銷，在大量插入場景下效能可提升 5~10 倍。

建議使用 UUID v7 的情境： 資料庫主鍵、時間序列資料、需要按建立時間排序的業務場景。UUID v4 則適合不需排序、純隨機標識的場景。

ULID 為什麼可以排序？

ULID 的前 48 位元儲存的是 Unix 毫秒時間戳（與 UUID v7 類似），因此按字典序排序就等同於按建立時間排序。這使得 ULID 在資料庫索引上比純隨機 ID 更友善。

此外，ULID 使用 Crockford Base32 編碼（排除了 I、L、O、U 等容易混淆的字元），整體長度僅 26 字元，比 UUID 的 36 字元更簡潔。時間戳的編碼佔前 10 字元，後 16 字元為亂數。

ULID 的另一個優點是：可以在同一毫秒內產生最多 2^80 個 ID，極端高併發場景下仍能保持唯一性。

Nano ID 為什麼越來越流行？

Nano ID 受到開發者歡迎的原因主要有以下幾點：

1. 體積極小： 原始程式碼僅約 130 bytes（gzip），對前端打包體積幾乎無影響。
2. 高效能： 使用 Node.js 的 crypto 模組或瀏覽器的 Web Crypto API，產生速度遠快於 UUID。
3. 自訂彈性： 可自由調整 ID 長度與字元集，在「唯一性」與「簡潔性」之間取得最佳平衡。
4. URL 安全： 預設使用 URL 安全字元集（A-Za-z0-9_-），無需額外編碼即可嵌入網址。
5. 被主流專案採用： 包括 Next.js、Nuxt、Hono 等框架、以及許多開源專案都使用 Nano ID 作為預設 ID 產生方案。

建立系統時如何選擇適合的 ID 格式？

選擇 ID 格式時可以根據以下幾點判斷：

需要時間排序且高安全性 → UUID v7
適合資料庫主鍵，128 位元亂度，支援全球唯一。

需要時間排序但希望更簡潔 → ULID
26 字元，可排序，適合對外公開的識別碼。

純隨機標識，相容性優先 → UUID v4
最廣為支援的格式，適合 API、外部系統整合。

高效能、輕量級前端 → Nano ID
短、快、可自訂，適合短期 Token、檔案命名、訂單編號。

需要安全性與水平擴展 → CUID2
專為水平擴展設計，內建碰撞防護機制。

簡短且人類可讀 → Short ID
適合邀請碼、優惠券代碼、短網址 slug。

ID 碰撞的機率有多高？真的不會重複嗎？

這是機率問題，並非「不會」而是「極難」。以 UUID v4 為例，有效位元數為 122 bits，理論上要產生約 2.71 × 10^18 個 ID 才有 50% 的碰撞機率（生日悖論）。

換算成直覺感受：
• 每秒產生 10 億個 UUID v4，連續 85 年後碰撞機率約為 50%
• 每秒產生 100 萬個 UUID v4，你的一生中看到碰撞的機率趨近於 0

ULID 和 Nano ID 也有類似等級的安全性。你可以使用本工具的「碰撞機率估算」功能，根據你的使用量計算具體的碰撞風險。

這些 ID 是純前端產生，真的安全嗎？

是的，本工具所有 ID 產生邏輯都使用瀏覽器的 Web Crypto API（crypto.getRandomValues / crypto.randomUUID），這是作業系統底層提供的密碼學安全亂數產生器 (CSPRNG)，與 HTTPS 加密使用的是同一層級的亂數來源。

所有運算都在你的瀏覽器中完成，產生的 ID 不會透過網路傳輸，伺服器不會儲存任何資料。你可以關閉網路後繼續使用本工具。

如果你需要更高安全性的 ID（例如包含機密資訊的場景），建議在本地端使用專用程式庫進行產生。

深入了解唯一識別碼：從 UUID 到 Nano ID 的完整指南

在現代軟體開發中，唯一識別碼（Unique Identifier）是構成系統基礎的重要元件。無論是資料庫主鍵、API 資源識別、使用者 ID、訂單編號還是檔案名稱，我們都需要一個可靠的機制來產生不重複的標識。

UUID：最廣泛使用的標準

UUID（Universally Unique Identifier）是一組 128 位元的識別碼標準（RFC 4122），其設計目標是在不需要中央協調機制的條件下，保證全球範圍的唯一性。最常見的 UUID v4 完全依賴亂數產生，而較新的 UUID v7 則結合了時間戳與亂數，提供時間有序的特性。

UUID 的優勢在於其標準化程度最高，幾乎所有程式語言和資料庫都有原生支援，非常適合跨系統、跨語言的應用場景。然而其 36 字元的長度在某些場合顯得冗長，且 v4 的純隨機特性對資料庫索引不夠友善。

ULID：可排序的現代替代方案

ULID（Universally Unique Lexicographically Sortable Identifier）由 Alizain Feerasta 於 2016 年提出，旨在解決 UUID 不可排序的問題。ULID 同樣為 128 位元，但編碼為 26 字元的 Crockford Base32 字串。其時間戳前綴確保了字典序排序即為時間序排序，且在同一毫秒內可產生多達 2^80 個唯一值。

Crockford Base32 編碼的額外好處是排除了容易混淆的字元（如 I、L、O、U），提高了人類閱讀與手動輸入的正確性。ULID 的大小寫不敏感特性也使其在 URL 中使用時更友善。

Nano ID：輕量級高效方案

Nano ID 由 Andrey Sitnik（也是 PostCSS 與 Autoprefixer 的作者）開發，是目前前端生態中最受歡迎的 ID 產生器之一。與 UUID 和 ULID 不同，Nano ID 不是固定格式的標準，而是一個可自訂的實作方案。其核心設計哲學是「在最小的體積下提供足夠的唯一性」。

Nano ID 使用 64 字元的 URL 安全字母表（包含 A-Z、a-z、0-9、- 和 _），預設長度 21 字元下可提供與 UUID v4 相同的 126 bits 亂度。透過調整長度參數，可在安全性與簡潔性之間靈活切換。

CUID2：水平擴展的防碰撞方案

CUID2 是 CUID 的第二代版本，由 Eric Elliott 建立，特別針對水平擴展（Horizontal Scaling）場景設計。CUID2 內部使用遞增計數器、亂數指紋以及雜湊函數，確保在分散式系統中即使沒有中央協調器也不會產生碰撞。

CUID2 的預設長度約為 24 字元，包含了編碼的指紋資訊，因此即使兩台伺服器在同一毫秒內產生 ID，結果也截然不同。這使得 CUID2 成為微服務架構與 Serverless 應用的理想選擇。

如何選擇？實務建議

如果你是建立新的 PostgreSQL 或 MySQL 資料表，並希望使用 UUID 作為主鍵，強烈建議選擇 UUID v7，它能大幅減少索引碎片化問題。如果你需要對外暴露 ID 且希望長度較短，ULID 或 Nano ID 是更好的選擇。對於安全性要求極高的水平擴展場景，CUID2 提供了額外的防碰撞保障。

無論你選擇哪種格式，都可以使用 ToolHub 的 ID 產生器快速生成測試資料，並透過碰撞機率計算器驗證你的選擇是否滿足業務需求。

唯一識別碼產生器 UUID / ULID / Nano ID