UUID v7 生成器：時間排序、不可猜測嘅本地化識別碼
UUID v7 將一個 48-bit Unix 毫秒時間戳嵌入識別碼開頭，後面跟隨隨機位元，令到每個 ID 可以按建立時間排序，同時保持密碼學強度嘅不可猜測性。呢個生成器頁面讓你喺瀏覽器內即時產生 1 至 100 個 UUID v7 識別碼，並提供大寫切換同連字符開關，所有處理都喺本地完成，唔會將任何資料送出到伺服器。
UUID v7 嘅結構：時間戳 + 隨機位元
UUID v7 係 128-bit 識別碼，文字表示為 36 個字元，格式係 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。頭 48-bit 係 Unix 毫秒時間戳（由 1970-01-01 00:00:00 UTC 起計嘅毫秒數），其餘 80-bit 由密碼學安全嘅隨機數產生器填充。呢個設計令 UUID v7 同時具備兩個重要特性：
- 按時間排序：因為時間戳放喺最前面，喺資料庫 B-tree 索引入面插入新記錄時，頁面分裂次數遠少於 UUID v4，提升寫入效能。
- 不可猜測性：隨機部分足夠長（80-bit），攻擊者無法透過已知 ID 推斷未來或過去嘅 ID。
注意：UUID v7 唔保證同一毫秒內產生嘅 ID 有嚴格排序──如果系統喺同一毫秒內產生大量 ID，排列次序取決於隨機部分，而唔係時間先後。
同 UUID v4 嘅關鍵差異：索引局部性
UUID v4 完全由隨機數構成，喺資料庫以主鍵插入時會隨機分散喺 B-tree 各頁，導致頻繁頁面分裂、快取命中率下降。UUID v7 將時間戳放喺開頭，新記錄傾向插入索引樹嘅最右位置，大幅減少頁面分裂次數。實際測試顯示，喺高並發寫入場景，UUID v7 嘅插入效能可比 v4 提升 20–50%，尤其喺 SSD 上效果更明顯。
但相同毫秒內嘅 ID 順序唔保證──若你嘅應用需要嚴格嘅跨記錄次序（例如事件溯源），需要額外機制（如序號或時間戳細化）來處理同一毫秒嘅情況。
生成器嘅操作方式同邊界情況
呢個頁面嘅輸入好簡單：
- 數量：1 至 100（改變時即時重新產生）
- 大寫：開關，輸出全部大寫字母
- 包含連字符：開關，輸出有無連字符（標準格式有連字符）
輸出會顯示一個列表，每個 ID 都可以獨立點擊複製，或者一次過複製全部。狀態欄會顯示「Ready.」、「Generated.」或「Copied all!」。
邊界情況要注意：
- 改變任何選項（數量、大寫、連字符）會立刻重新產生所有 ID，舊 ID 消失。
- 當你選擇不含連字符嘅格式，輸出長度係 32 個字元（純十六進制），但內部結構仍然係 128-bit UUID v7。
- 由於瀏覽器隨機數產生器嘅質素，現代瀏覽器（Chrome、Firefox、Safari）使用
crypto.getRandomValues()，足夠支援密碼學應用。
誰需要呢個工具
- 分散式系統開發者：需要分散且時間可排序嘅主鍵，避免中央序列生成器成為瓶頸。
- 資料庫管理員：想減少 UUID v4 造成嘅索引碎片，尤其係高寫入量嘅 OLTP 系統。
- 安全工程師：需要不可猜測嘅識別碼，同時容許按時間過濾或排序（例如審計日誌、API 金鑰）。
- 從 v4 遷移嘅團隊：想轉用時間排序格式，但唔想改用 ULID 或 NanoID（佢哋有唔同字元集同長度），保留 UUID 標準格式以便與現有工具相容。
常見誤解同最佳實踐
- 「UUID v7 保證全局嚴格排序」：錯。同一毫秒內唔保證順序；若需要嚴格排序，應改用有序時間戳（例如精確到微秒嘅系統時間）加上序號。
- 「大寫 UUID 係壞習慣」：標準 RFC 9562（UUID v7 嘅最終規範）指定用大寫字母表示十六進制？其實 RFC 容許小寫或大寫，但大部分實作用小寫。呢個工具提供選項，方便複製貼上時符合系統要求（例如某些數據庫工具偏好大寫）。
- 「冇連字符嘅 UUID 係 v7 嗎？」：係。UUID v7 嘅內部結構同連字符無關。移除連字符只影響文字表示，唔改變 ID 內容或排序特性。
常見問題（FAQ）
問：UUID v7 同 ULID 有咩分別？ 答：兩者都係時間排序加隨機，但 UUID v7 用 36 字元、標準 UUID 格式；ULID 用 26 字元、Crockford Base32 編碼。UUID v7 嘅時間戳精度係毫秒（48-bit），ULID 係毫秒（48-bit）但將隨機部分編碼得更緊湊。選擇取決於你系統需要嘅文字長度同現有 UUID 工具鏈相容性。
問：可以喺生產環境用呢個工具產生數據庫主鍵嗎？
答：可以，但要注意：工具一次性產生 1–100 個 ID，適合離線設定或測試。生產系統應該使用伺服器端嘅 UUID v7 庫（例如 PHP 嘅 uuid_create()、Python 嘅 uuid.uuid7()）以確保時間戳準確同隨機數來源可控。
問：同一個毫秒內產生嘅 ID 會撞嗎？ 答：極低機率。80-bit 隨機部分嘅碰撞機率喺單一毫秒內產生 100 個 ID 時極低（約 2^80 分一）。但嚴格嚟講，唔保證順序，只保證極低碰撞率。
問：我應該用大寫定小寫？ 答：按系統標準決定。數據庫內部以二進制儲存，字元大小寫唔影響儲存或排序。但若你嘅系統（例如某些 CLI 工具）只接受大寫，就開大寫。
問：點解改變選項會即刻清除舊 ID？ 答：為咗確保輸出一致。如果保留舊 ID，使用者可能混淆舊設定同新設定嘅結果。每次變更都代表一個新批次。
問：呢個工具安全嗎？會傳送資料去你伺服器嗎？
答：唔會。所有 ID 都喺你瀏覽器用 crypto.getRandomValues() 產生，無任何網絡請求。你可以斷網使用。