UUID v4 的結構與隨機性
UUID v4（第 4 版通用唯一識別碼）是 128 位元的識別碼，其中 122 位元完全來自密碼學強度的隨機數，剩下的 6 位元用於標示版本（第 13 個字元的高 4 位元固定為 4）與變體（第 17 個字元的高 2 位元固定為 10）。這個頁面產生的每個字串，無論是標準的 36 字元格式（8‑4‑4‑4‑12）或是移除連字號後的 32 字元格式，背後都使用瀏覽器的 crypto.randomUUID 或等效方法，確保每一位隨機位元都是不可預測的。
因為隨機位元佔了絕大部分，UUID v4 的排序行為完全沒有時間或順序暗示。這與 UUID v7（時間排序）或 ULID 截然不同——後兩者內嵌了時間戳記，產生的識別碼大致按建立順序遞增。如果你把 UUID v4 當作資料庫主鍵插入 B‑tree 索引，它會散落在索引樹的各個節點，導致頁面分裂（page split）與索引碎片化，寫入效能隨著數據量上升而明顯下降。這是許多生產環境選擇 UUID v7 或 ULID 而非 v4 的原因之一，但若你不需要時間相關性，v4 的純隨機性反而是優點。
碰撞機率與熵的實際意義
122 位元隨機性意味著總共有 2¹²² 種可能的取值——大約是 5.3×10³⁶。根據生日悖論，要在 50% 機率下發生一次碰撞，需要產生約 2⁶¹ 個 UUID（大約 2.3×10¹⁸）。換句話說，每秒產生十億個 UUID，連續產生 73 億年才有一半機率出現一次碰撞。這個頁面上允許一次產生最多 100 個，對於任何合理規模的應用（例如分佈式系統的追蹤 ID、API 金鑰、事件辨識符）都完全足夠。
然而，碰撞機率不是零。如果系統需要絕對保證不重複（例如檔案系統的 inode），就應該使用其他機制（如遞增序列或集中式分配）。但對於絕大多數軟體場景，122 位元隨機性的碰撞風險遠低於硬體錯誤或程式碼邏輯錯誤，可以忽略不計。
格式自訂的取捨與相容性
頁面提供了兩個開關：大寫 與 連字號。這兩個選項只對 UUID v4（與 v7）有意義，因為其他 ID 類型（ULID、NanoID）有自己固定的字元集與分隔規範。
- 連字號：標準 UUID 字串的 8‑4‑4‑4‑12 格式是 RFC 4122 定義的規範表示法，便於人類閱讀與分割區段。移除連字號後得到 32 個十六進位字元，常用於 URL 查詢參數或檔案名稱（避免 URL 編碼問題）。請注意，部分系統（如某些資料庫字串函數）預期 UUID 帶有連字號，若省略可能導致字串比對失敗。
- 大寫：十六進位數字
a-f轉為A-F。大小寫在絕大多數系統中是不敏感的（例如 MySQL 的字串比對預設不區分大小寫），但部分檔案系統或密碼學 API 可能區分。此外，大寫字串在視覺上較容易與數字6或b混淆嗎？不一定，但有些團隊偏好全大寫以統一風格。這個頁面在切換大小寫時會立即重新產生所有 ID，確保大小寫變更後的隨機值仍然是全新的。
數量上限設定為 100 是實用考量：一方面避免瀏覽器一次處理過多 DOM 操作造成卡頓；另一方面，100 個 UUID 在螢幕上已可完整顯示，滿足大量批次測試的需求。若需要更多，可以重複點擊「全部複製」後貼到文字檔案再合併。
瀏覽器端產生與安全模型
所有 UUID 的產生完全在瀏覽器內執行，不使用任何遠端 API。程式碼依賴 window.crypto.getRandomValues 或 crypto.randomUUID，這兩個介面由瀏覽器的隨機數產生器（通常是作業系統層級的 CSPRNG）驅動，符合密碼學安全需求。因此，產生的 UUID v4 可以用於跨站請求偽造（CSRF）令牌、重置密碼連結、或任何需要不可猜測性的場合。
因為沒有網路請求，頁面可以在離線狀態下執行（前提是頁面本身已載入）。這也避免了識別碼在伺服器端被記錄或洩漏的可能。對於安全工程師而言，這是顯著的隱私優勢——你不必擔心 ID 產生過程被中間人攔截或伺服器側寫日誌。
使用場景與常見錯誤
| 場景 | 說明 | 建議 |
|---|---|---|
| 分佈式資料庫主鍵 | 多個寫入節點無需協調即可產生唯一鍵 | 注意索引碎片，考慮使用 UUID v7 或 ULID 若寫入量極大 |
| API 請求 ID / 交易追蹤 | 需要每筆請求獨立且不可預測 | UUID v4 適合，但長度較長（36 字元），可考慮移除連字號 |
| 匿名使用者識別碼 | 不應暴露建立時間或順序 | UUID v4 是最佳選擇，完全隨機 |
| 測試資料填充 | 快速產生大量唯一值 | 用上限 100 多次產生，或複製全部後用腳本重複 |
常見的錯誤包括：忘記移除連字號後直接放入需純十六進位字串的上下文中導致格式錯誤；誤以為 UUID v4 會依時間排序而將其用在需要遞增索引的集群環境；在短時間內重複產生大量 UUID 並預期索引效能不受影響。使用這個頁面時，建議先思考你的下游系統是否對大小寫敏感、是否接受連字號，以及是否需要順序性。
常見問題（FAQ）
Q：UUID v4 的碰撞機率有多低？
大約需要產生 2⁶¹ 個（約 2.3×10¹⁸）才有 50% 機率發生一次碰撞。以實務而言，100 個以內的樣本絕無碰撞。
Q：為什麼 UUID v4 不適合當資料庫主鍵？
因為它是完全隨機的，插入時會頻繁造成 B‑tree 節點分裂，導致寫入效能下降與儲存空間浪費。若無法接受索引碎片，可改用 UUID v7 或 ULID。
Q：移除連字號會影響唯一性嗎？
不會。連字號只是為了可讀性，不是 ID 的一部分。移除後仍然是相同的 32 個十六進位字元，唯一性不變。
Q：大寫與小寫 UUID 哪個比較好？
取決於相容性。若你的系統不區分大小寫（資料庫或檔案系統），兩者都可行。大寫在掃描時可能較易辨識，但小寫是 RFC 4122 的標準建議。
Q：瀏覽器產生的 UUID 真的安全嗎？
是的。瀏覽器使用作業系統的 CSPRNG（在 Linux 上是 /dev/urandom，Windows 上是 CNG），足夠用於絕大多數安全用途，包括令牌與金鑰。
Q：為什麼數量上限是 100？
為了避免頁面回應遲緩，同時確保所有 ID 能在單一畫面內完整呈現。若需要更多，可多次產生後合併結果。