這個工具的用途
UUID（RFC 9562）是 128-bit 的識別碼，可以在不需要伺服器協調的情況下 本地產生，且基本上不會重複。本工具產生 UUID v4 （隨機）用於一般情境，與 UUID v7 （時間戳前綴）用於需要排序的資料庫主鍵。所有產生都透過瀏覽器內建的 Web Crypto API 完成。
使用步驟
選擇版本、選擇數量（1、10、100，或自訂），按下 Generate。可一鍵複製全部，或下載為文字檔。
v4 範例：
f47ac10b-58cc-4372-a567-0e02b2c3d479v7 範例（前 48 bits 是 Unix-ms 時間戳——這顆是 2024-07-04 14:23 UTC 產生）：
0190b3ac-3e80-72f8-9a7e-1d4b6e5f8c21限制與邊界情況
- v4 完全隨機。 每個 UUID 獨立——分布性極佳，但對 B-tree 索引非常不友善（每筆插入都落在隨機位置）。
- v7 帶時間戳。 字典序排序剛好等於建立時間，DB 索引能維持緊湊。代價：前 48 bits 會洩漏建立時間（看到 UUID 的人都看得到）。
- 完整規格請看 RFC 9562。v1/v3/v5/v6/v8 也存在但現代很少是正確選擇。
- 兩個版本都是 128 bits，寫成 32 個 hex 字元，以連字號分隔在 8/12/16/20 位置。
常見問題
- 該用 v4 還是 v7？
- 不會放進排序索引的（request ID、session token、檔名）用 v4。資料庫主鍵——尤其是 B-tree 系統（PostgreSQL、MySQL、SQLite）——用 v7，避免隨機 ID 造成的寫入放大。
- 輸出是密碼學等級隨機嗎？
- 是。v4 和 v7 都用 crypto.getRandomValues / crypto.randomUUID，瀏覽器底層使用 CSPRNG，不是 Math.random()。
- 有任何東西會送到伺服器嗎？
- 不會。所有產生都透過瀏覽器內的 Web Crypto API，本頁從不上傳任何資料。
- 為什麼 v7 可以排序？
- 前 48 bits 是建立當下的 Unix 毫秒時間戳。較晚產生的 UUID 以字串比較會排在較早產生的之後，不需特殊索引。
- 一次可以產生多少？
- 最多 1,000 個。需要更多可以多按幾次，或直接呼叫 UUID lib。
- v4 真的不會撞嗎？
- 數學上可能，實務上不會。122 bits 熵代表你要產 ~2.7 × 10^18 個 v4 UUID 才有 50% 機率撞到一次。