UUID v7 生成器：內建時序的不可猜測識別碼
這個頁面的核心功能很明確：你給定一個數量（1 到 100 之間），選擇幾項顯示偏好，它會即刻回傳一份依時間排序、36 字元、不可猜測的 UUID v7 識別碼清單。你可以逐個複製，也可以一次全部複製。
UUID v7 的結構與規格
UUID v7 是一種 128 位元的識別碼規範，其文字表示為 36 個字元。它與廣為人知的 UUID v4 最大的不同，在於開頭嵌入了一個 48 位元的 Unix 毫秒時間戳記。這意味著，當你比較兩個在不同時間點產生的 UUID v7 時，光是看前幾個字元就能知道誰先誰後。時間戳記之後的剩餘位元，則由高品質的亂數填充，確保無法被猜測或用來推算其他已產生的識別碼。整個 128 位元結構最終以 8-4-4-4-12 的 36 字元格式呈現（含連字號）。
解決 UUID v4 的索引局部性問題
資料庫的 B-tree 索引在處理 UUID v4 時會遇到一個實務痛點。UUID v4 是完全隨機的，插入資料庫的新記錄主鍵會散落在索引樹的各個葉子節點上，導致索引頁頻繁分裂、快取命中率下降，最終拖慢寫入效能。UUID v7 的時間前綴讓新產生的識別碼在實體儲存上彼此靠近，資料庫得以更有效率地批次寫入。這項改進在大量併發寫入的場景下尤其明顯，這也是許多開發者從 UUID v4 遷移到這類時序型識別碼的主因。
使用方式與即時反饋
頁面上提供了三個核心控制項：
- 數量：輸入值限定在 1 到 100 之間。任何超出邊界的無效輸入，工具都會以最接近的有效整數處理，並自動重新產生清單。
- 轉為大寫：開關切換後，所有 UUID 字元（a-f）立即改為大寫格式。這對於某些系統的輸入規範或單純的閱讀偏好很有用。
- 包含連字號：關閉後，UUID 會以連續的 32 個十六進位字元呈現，省略分隔用的連字號。標準的 UUID 格式包含連字號，但有些情境（例如檔名或部分 URI）會偏好無連字號的版本。
每次修改任一選項，工具會立即在瀏覽器中重新產生整批識別碼。狀態列會依序顯示「Ready.」、「Generated.」，以及複製全部後的「Copied all!」。點擊單一識別碼即可將該 ID 複製到剪貼簿。
排序保證與其他時序型識別碼的比較
UUID v7 的排序能力建立在時間戳記上，但它並不保證同一毫秒內產生的 ID 有嚴格的順序。如果兩個識別碼產生於相同的毫秒，它們的相對順序不可預測。這與 ULID 類似：ULID 也嵌入時間戳記，在同一毫秒內同樣不保證嚴格排序。相比之下，UUID v4 完全不具備時序性。而 NanoID 則不假設時間因素，其排序性完全取決於實作方式。
這個特性在設計分散式系統時至關重要。如果應用需要嚴格的全域排序，即使是同一毫秒內的事件也不能含糊，那麼 UUID v7 或 ULID 可能不足，需要考慮 Snowflake 這類包含序列號的格式。但對於大多數只需要「大致按時間分組」或「近期產生的 ID 彼此靠近」的情境，UUID v7 的排序保證已經足夠。
瀏覽器端產生的安全性與隱私
所有識別碼的產生完全在瀏覽器本地完成，呼叫的是瀏覽器內建的 Crypto.getRandomValues() API。這個 API 由作業系統層級的亂數來源支援，提供密碼學上安全的亂數。沒有任何識別碼或使用者輸入被傳送到 BroBroGo 的伺服器。這表示即使生成大量識別碼，也不會有網路延遲，且完全保護了使用者的隱私。
常見問題（FAQ）
問：這個工具一次可以產生多少個 UUID v7？ 答：介於 1 到 100 個之間。如果輸入超出此範圍，工具會以最接近的有效數字處理。
問：UUID v7 和 UUID v4 的主要差別是什麼？ 答：UUID v7 開頭是時間戳記，因此產生的識別碼可以按時間大致排序，對資料庫索引更友善；UUID v4 是完全隨機的，排序性極差，但兩者在安全性上都使用高品質亂數。
問：同一個毫秒產生的兩個 UUID v7，誰比較大？ 答：不保證。UUID v7 規範未對同一毫秒內的順序做出定義，因此兩者的相對大小不可預測。
問：我可以複製單筆識別碼就好嗎？ 答：可以。點擊清單中的任何一筆識別碼，就可以將該筆複製到剪貼簿。
問：產生的識別碼是否會上傳到網路？ 答：不會。所有識別碼都在你的瀏覽器本地使用 Crypto.getRandomValues() 產生，不會傳送到任何伺服器。
問：大寫和連字號的選項會影響 UUID v7 的規格嗎？ 答：不影響。大小寫和連字號僅是顯示格式偏好，UUID v7 的 128 位元內容完全相同。