UUID v4 隨機識別碼生成器：原理、格式與實際應用
UUID v4（第四版通用唯一識別碼）係一種基於 122 位真隨機數嘅識別碼格式。呢個工具嘅生成器完全喺瀏覽器內運作，每次生成一至一百個 36 字符嘅標準字串（或去除連字符後 32 字符）。與其 UUID 家族成員（例如基於時間順序嘅 v7）唔同，v4 嘅排序完全隨機，冇任何時序資訊夾雜其中。
結構解構：128 位元入面有幾多係真隨機？
一個 UUID v4 嘅標準格式係 8-4-4-4-12，合共 32 個十六進制字符加 4 個連字符。呢 32 個字符代表 128 位元（bit），但唔係全部 128 bit 都用嚟裝隨機資料。根據 RFC 4122，版本位（第 13 個字符必須係「4」）同變體位（第 17 個字符嘅高兩位固定為「10」，即字符範圍只限 8、9、a、b）合共佔用 6 bit。所以實際可用嘅隨機熵只有 128 - 6 = 122 bit。呢 122 bit 嘅純隨機性決定咗 v4 嘅不可預測性同碰撞概率。
格式自訂：大楷字母同連字符嘅取捨
工具提供兩個格式開關：大楷輸出同埋隱藏連字符。
- 大楷開關：預設係細楷（a-f），開啟後全部 hex 字母變成大楷（A-F）。呢個純粹係顯示偏好，唔影響識別碼嘅唯一性。但要注意某啲系統（例如舊版 Windows 登錄檔或某啲檔案系統）對大小楷敏感，轉換時要一致。
- 隱藏連字符：關閉後輸出變成 32 個連續 hex 字符。呢種形式常用於 URL 參數、檔案名或者需要壓縮儲存嘅場景。但留意，無連字符嘅版本較易出現肉眼判讀錯誤，尤其係 0/O、1/l 容易混淆嘅字符。
格式對照表：
| 選項組合 | 輸出範例 | 字符長度 |
|---|---|---|
| 細楷 + 連字符 | 550e8400-e29b-41d4-a716-446655440000 | 36 |
| 大楷 + 連字符 | 550E8400-E29B-41D4-A716-446655440000 | 36 |
| 細楷 + 無連字符 | 550e8400e29b41d4a716446655440000 | 32 |
| 大楷 + 無連字符 | 550E8400E29B41D4A716446655440000 | 32 |
任何格式變更都會即時重新生成所有 ID，確保每個新選項都對應全新隨機值。
碰撞概率：122 bit 隨機性夠唔夠安全？
碰撞（兩個 v4 撞同一個值）嘅概率可以透過近似公式估算：對於 n 個隨機 UUID，至少一次碰撞嘅機率約為 1 - e^(-n² / 2¹²³)。以 122 bit 計，總空間係 2¹²² ≈ 5.3 × 10³⁶。假設生成 10 億個（10⁹）v4，碰撞率大約係 10⁻¹⁸ 級別，遠低於硬件錯誤概率。就算生成 1 萬億個，碰撞率仍然低於百萬分之一。
呢個數字嘅實際意義：
- API 令牌：唔需要中央伺服器協調，每個離線節點都可以安全生成獨一無二嘅令牌。
- 事件追蹤 ID：就算每秒產生一百萬個事件，連續運行數萬年都唔會出現碰撞。
但要注意，呢個保證只適用於真隨機源。瀏覽器嘅 crypto.randomUUID() 或 crypto.getRandomValues() 使用操作系統提供嘅強隨機數生成器，符合密碼學安全要求（CSPRNG）。所以呢個工具生成嘅 v4 適合用於安全場景。
對資料庫效能嘅影響：點解亂序係雙面刃？
UUID v4 嘅隨機排序對資料庫索引（尤其係 B-tree）造成顯著問題。假設一個 InnoDB 表使用 UUID v4 做主鍵，每次插入新記錄時，索引樹需要隨機插入頁面，導致大量頁面分裂（page split）同葉節點重新平衡。呢種隨機寫入模式會令索引碎片化（fragmentation）急劇增加，寫入速度下降，快取命中率降低。
實際表現比較（範例數字，視乎硬件）：
- 自增整數主鍵：每小時可插入約 500 萬行，索引碎片率 < 5%。
- UUID v4 主鍵：同一硬件每小時約 200 萬行，索引碎片率 > 30%。
解決方法：
- 將 UUID v4 儲存為二進制（BINARY(16)）而非字符串，可縮小索引體積。
- 使用時間排序嘅 UUID v7 或 ULID，佢哋生成時夾帶時間戳，插入順序接近遞增，大幅減少頁面分裂。
- 如果必須用 v4（例如離線生成），可以考慮將主鍵設為自增整數，額外加一個 UUID 列做唯一約束。
工具頁面同時提供 v7、ULID 同 NanoID 選項，讓用家根據排序需求選擇合適格式。
使用場景：邊啲情況非 v4 不可？
- 分佈式離線系統：多個節點（例如手機 app 或 IoT 裝置）無法連接中央資料庫，需要各自生成唯一 ID，v4 嘅隨機性確保冇衝突，無需協調。
- 安全令牌與 session ID：攻擊者如果能夠推測 ID 生成規律（例如基於時間戳），就可以預測或列舉有效令牌。v4 嘅不可預測性杜絕咗呢類攻擊。
- 私隱保護：時間戳生成嘅 ID 可能間接暴露事件發生時間或用戶活動規律。v4 完全隱藏時序資訊。
- 測試數據填充：需要大量逼真嘅隨機識別碼進行壓力測試或樣本數據庫填充。
瀏覽器端生成嘅優勢
所有 ID 生成都喺用戶瀏覽器內完成，無需網絡請求。呢點帶來：
- 低延遲：即點即生成，即使一次過要 100 個都係毫秒級完成。
- 私隱安全：生成過程唔會將任何數據傳去伺服器，敏感資訊（例如內部測試用嘅 ID）唔會外洩。
- 離線可用：斷網情況下工具依然正常運作。
技術實現依賴現代瀏覽器標準 API，無需安裝任何插件或執行環境。
常見問題 FAQ
問：生成 100 個 UUID v4 會唔會消耗好多系統資源？ 答：唔會。每個 UUID 生成涉及 16 字節隨機數同格式化輸出，CPU 時間極短。瀏覽器內嘅 CSPRNG 效率非常高，一次生成 100 個只需幾微秒。
問：「Ready.」同「Generated.」狀態有咩分別？ 答：「Ready.」表示頁面載入完成但尚未有任何生成動作；「Generated.」表示已經根據當前設定生成了 ID 列表。改變任何選項後狀態會回退到「Ready.」再即時變為「Generated.」。
問：點解我複製所有 ID 後見到「Copied all!」但個別點擊冇反應？ 答：個別點擊 ID 會將嗰個特定識別碼複製到剪貼簿，唔會有狀態提示（除咗瀏覽器本身嘅通知）。「Copied all!」係批次複製完成後嘅短暫訊息。
問：我可以將生成嘅 ID 用嚟做生產環境嘅主鍵嗎？ 答：可以，但要考慮資料庫索引碎片問題。如果寫入量好低（例如每小時幾千行），影響有限。高寫入場景建議使用 UUID v7 或自增整數。
問：輸出長度點解有時 36 有時 32？ 答：呢個取決於「Include hyphens」設定。開啟時用標準格式（8-4-4-4-12，共 36 字符），關閉時變成連續 32 字符，順序不變。
問：工具保證唯一性嗎？ 答：無法絕對保證，但碰撞概率極低（約 10⁻³⁶ 級別）。實務上可以當做唯一，但如果需要硬性保證（例如法定文件識別），建議配合其他檢查機制。