通用唯一識別碼（UUID v4）即時生成器
UUID（Universally Unique Identifier）v4 是互聯網工程任務組（IETF）喺 RFC 4122 中定義嘅標準格式之一，特點係完全依賴隨機數產生標識符，唔包含時間戳或機器識別資料。呢個頁面嘅工具可以即時生成一至一百個 UUID v4 字串，讓開發者、系統管理員或者測試人員快速取得具備高隨機性嘅標識符。你只需設定數量、是否大寫同是否保留連字號，就能得到標準 8-4-4-4-12 格式嘅結果。所有生成過程都喺瀏覽器本地完成，唔會將任何資料送出到伺服器，保障隱私同安全。
隨機本質：122 位元亂數與碰撞概率
UUID v4 嘅隨機性來自 122 個位元（bit）嘅亂數。實際結構係 16 個字節（octet），其中 4 個位元用嚟標示版本（版本 4），另外 2 個位元標示變體（variant），淨低 122 個位元全部由加密級別嘅偽隨機數生成器（CSPRNG）產生。呢個設計令每一個 UUID v4 理論上無法預測，而且碰撞嘅機率極低——假設每秒生成 10 億個 UUID，要連續約 100 年先有大約 50% 機會出現一次重複。因為呢個特性，UUID v4 成日用喺需要高度唯一性但又唔需要排序嘅場合，例如安全令牌、會話 ID、或者匿名化嘅實體識別碼。
呢個工具背後嘅亂數來源係瀏覽器提供嘅 crypto.getRandomValues() 方法（喺支援嘅環境下），屬於操作系統層面嘅真隨機數或者高品質偽隨機數，通過標準測試如 NIST SP 800-90A/B/C。因此，生成出嚟嘅 UUID v4 符合 RFC 4122 嘅隨機性要求，並保證版本同變體位元正確設置。
輸出格式控制：大小寫與連字符
預設情況下，工具輸出嘅 UUID v4 係全部小寫英文字母加連字號，例如 550e8400-e29b-41d4-a716-446655440000。你可以透過「Uppercase」（大寫）開關將 a-f 轉為大寫 A-F，得到例如 550E8400-E29B-41D4-A716-446655440000。連字號開關則控制係咪保留嗰四個連字號；關閉連字號後會變成 32 個連續嘅十六進制字符，例如 550e8400e29b41d4a716446655440000。呢兩個選項只影響顯示格式，唔會改變底層嘅 122 位元亂數內容。
注意：改變任何選項（包括數量、大小寫、連字號）都會令整個列表重新生成，防止你同時見到唔同設定下嘅舊結果。如果你只需要一個 UUID，可以設定數量為 1，然後點擊該 ID 直接複製到剪貼簿；如果需要全部，就用「Copy all」（全部複製）按鈕。
對數據庫索引嘅影響：排序隨機性嘅代價
UUID v4 嘅隨機分佈雖然帶嚟高安全性，但同時引入一個常見嘅數據庫效能問題：作為主鍵時會導致 B-tree 索引頻繁分裂（page split）。因為 UUID v4 產生嘅數值完全無序，新插入嘅記錄可能分佈喺索引樹嘅任何位置，令 InnoDB 等行儲存引擎需要不斷重組頁面，影響寫入效能同快取命中率。相比之下，時間有序嘅 UUID v7 或者 ULID 會按時間順序生成，顯著減少索引碎片。
因此，呢個工具嘅「What makes this page different」部分特別強調：UUID v4 嘅排序係任意嘅，唔帶任何時間資訊。如果你使用關聯式數據庫而且預計寫入量好大，應該考慮改用時間根基嘅識別符；但如果你嘅應用對唯一性要求高於寫入效能，或者你唔想暴露生成時間，UUID v4 仍然係合適選擇。對於無關數據庫排序嘅場合，例如作為外部展示ID、日誌追蹤ID或者測試用嘅偽隨機鍵，UUID v4 嘅隨機性反而係優點。
操作流程與狀態提示
工具嘅互動設計非常直接：你首先從「Format」（格式）下拉選單揀選「UUID v4」（其他選項如 UUID v7、ULID、NanoID 會改變對應選項，但呢篇文章集中討論 UUID v4）。然後設定「Count」（數量），範圍係 1 到 100 之間嘅整數。之後可以按需要開關「Uppercase」同「Include hyphens」。當你變更任何設定，工具會自動重新生成所有 ID，並顯示狀態訊息：「Ready.」係初始狀態；生成成功後轉為「Generated.」；當你按「Copy all」複製全部 ID 後，狀態會短暫顯示「Copied all!」。
每個獨立嘅 UUID v4 字串都係可點擊嘅，單擊就會將該 ID 複製到系統剪貼簿。呢種設計容許你逐個提取 ID 或者一次過取得成批結果，方便整合到程式碼、CSV 檔案或者設定檔入面。所有操作都唔需要網絡連線，離線環境下仍然可以生成，因為演算法完全喺瀏覽器內執行。
常見錯誤與實用建議
- 誤解 v4 為時間排序：有啲開發者假定 UUID 嘅字面順序對應生成先後，但 UUID v4 無呢個特性。如果你需要按時間排序，請改用 v7 或 ULID。
- 剪貼簿安全性：喺共享電腦上生成敏感 ID（例如認證令牌）後，剪貼簿會被其他應用程式讀取。建議生成後立即貼上到目標位置，然後清除剪貼簿（例如複製一段空白文字取代）。
- 過量生成：每次生成最多 100 個 ID；如果需要更多，可以分多次生成，但留意碰撞概率保持極低，即使生成數百萬個 ID，碰撞風險仍然可以忽略。
- 大小寫與應用兼容性：某些系統區分大小寫（例如 Linux 檔案系統、部分 API 庫），而 UUID 規格本身唔要求特定大小寫。如果你嘅依賴區分大小寫，請確保格式一致。
- 連字符與資料傳輸：去掉連字符嘅 32 字符字串較短，節省少量儲存空間，但失去人眼可讀性。大部分 UUID 處理庫都接受兩種格式，但建議跟隨 RFC 4122 嘅連字符版本以保持標準化。
常見問題
Q1: UUID v4 嘅 122 位元隨機性係點樣計算出嚟？
每個 UUID v4 有 128 位元，其中版本位元（4 位元）同變體位元（2 位元）係固定嘅，淨低 122 位元由亂數填滿。因此實際可能嘅數值總數係 2^122 ≈ 5.3 × 10^36，係一個天文數字。
Q2: 將 UUID 轉為大寫會影響唯一性嗎？
唔會。大寫只係顯示方式，底層嘅二進制同十六進制數值完全一樣。唯一性完全取決於亂數部分，與大小寫表示無關。
Q3: 點解改變選項就要重新生成所有 ID？
呢個係設計上嘅一致約束：唔同設定之下嘅輸出唔應該混合顯示。例如你由 5 個 ID 改為 10 個 ID，原嚟嗰 5 個 ID 已經唔對應新設定；同樣，開關大小寫後，原有 ID 嘅字母大小寫狀態改變，如果保留舊 ID 會造成混淆。所以工具直接清空並重新生成。
Q4: 生成嘅 UUID 可以用喺生產環境做主鍵嗎？
可以，但要考慮數據庫效能。如果你嘅應用寫入量好低（例如每日幾百條記錄），UUID v4 作為主鍵係可接受嘅。但高寫入場景建議改用時間有序嘅 UUID v7，或者考慮自增整數主鍵配合其他唯一約束。
Q5: 呢個工具喺離線時用到嗎？
用到。所有 JavaScript 程式碼同亂數源都喺你瀏覽器內執行，唔需要連線去伺服器。只要頁面已經加載過一次（或瀏覽器快取保持），即使無網絡都可以生成 UUID。
Q6: 我可以生成超過 100 個 ID 嗎？
工具嘅數字輸入限制喺 1 到 100。如果你需要超過 100 個 ID，可以分多次生成，每次分別複製。碰撞概率極低，唔使擔心不同批次之間重複。