UUID 是什么

UUID (Universally Unique IDentifier) 通用唯一識別碼 ，也稱為 GUID (Globally Unique IDentifier) 全球唯一標識符。

UUID是一個長度為128位的標志符，能夠在時間和空間上確保其唯一性。UUID最初應用于Apollo網絡計算系統，隨后在Open Software Foundation（OSF）的分布式計算環境（DCE）中得到應用。可讓分布式系統可以不借助中心節點，就可以生成唯一標識， 比如唯一的ID進行日志記錄。

并被微軟Windows平臺采用。Windows 舉例2個使用場景：

• COM組件通過GUID 來定義類標識符（CLSID）、接口標識符（IID）以及其他重要的標識，確保在整個系統中不會發生命名沖突。

圖片

截圖_20242927042948.png

• Windows注冊表中很多項都使用GUID作為子鍵名，以便為特定程序或功能提供一個全球唯一的注冊表路徑。

圖片

UUID之所以被廣泛采用，主要原因之一是它們的分配不需要中心管理機構介入。其具有唯一性和持久性，它們非常適合用作統一資源名稱（URN）。UUID能夠無需注冊過程就能生成新的標識符的獨特優點，使得UUID成為創建成本最低的URN類型之一。

那么UUID會重復嘛，由于UUID具有固定的大小并包含時間字段，在特定算法下，隨著時間推移，理論上在大約公元3400年左右會出現值的循環，所以問題不大。

由于UUID是一個128位的長的標志符，為了便于閱讀和顯示，通常會將這個大整數轉換成32（不包含連接符）個十六進制字符組成的字符串形式。如下

crypto.randomUUID()
// 4d93f326-3f48-4a43-929d-b6489f4754b5

`${crypto.randomUUID()}`.length 
// 長度：36

`${crypto.randomUUID()}`.replace(/-/g, '').length
// 去掉連接符：32

這128位的組成，以及是怎么變成32位的十六進制字符的，繼續往下看：

UUID 的結構

UUID看似雜亂無章，其實內有乾坤，慢慢道來。

必須了解的

• 比特（bit）：二進制數字系統中的基本單位。一個比特可以代表二進制中的一個0或1。
• 位（通常情況下與比特同義）：二進制數系統中的一位，同樣表示0或1。
• 字節（Byte）：字節是計算機中更常用的單位，用于衡量數據存儲容量和傳輸速率。1字節等于8個比特。

總結起來就是：

• 1 字節 = 8 位
• 1 位 = 1 比特

128位轉為32個十六進制字符， 這個十六進制字符是什么呢，其專業名字為hexDigit，是UUID中我們肉眼可見的最小單元。

hexDigit

hexDigit ，   十六進制數字字符，是一個長度為4比特，可以表示0（0b000）到15（0b1111）之間數值。其能轉為16進制的相對應符號，其取值范圍為 0-9，a-f, A-F, 即0123456789abcdefABCDEF某一個值。

所以， hexDigit 可以粗暴的理解為 0123456789abcdefABCDEF某一個值。

(0b1000).toString(16)     // 8
 (0b1111).toString(16)     // F

此外，還有一個hexOctet， 兩個連續hexDigit組成的序列， 占8個比特，即一個字節。

UUID 基本結構

在協議 RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace[1] 的 4.1.2.  Layout and Byte Order[2] 有結構圖：

圖片

這個圖有點小迷惑， 最上面的  0,1,2,3 不是表示位數，就是簡單的表示10位數的值，9之后就是 10， 11， 12等等。

這圖不太好理解，換一張手工畫的圖（UUID 10類型的V4版本）：10類型和V4版本后續會解釋

圖片

128比特，16個字節即 16 hexOctet，就被如下瓜分了。

要想完整理解這個 6 部分組成，必然要理解備注中被加粗的幾個概念。保留位，版本， 時間戳， 時鐘序列 ，節點標志符

類型(變體) 和保留位

UUID可以分為四種類型（變體），怎么識別是哪種類型（變體呢），UUID有對應的Variant字段去標記，可以參見協議的 4.1.1.  Variant[3]部分。

variant字段位于UUID的第8個字節 即 clock_seq_hi_and_reserved 部分的第6-7位。

圖片

以外所有其他位的含義都是依據variant字段中的比特位設置來解讀的。從這個意義上講，variant字段更準確地說可以被稱作類型字段；然而為了與歷史文檔兼容，仍沿用“variant”這一術語。

下表列出了variant字段可能的內容，其中字母"x"表示無關緊要或不關心的值：

• Msb0（最高有效位0）：此為最高位。
• Msb1：次高位。
• Msb2：第三高位。

類型（變體）的標志符可以是 2位也可是3位，本文圍繞的的是 RFC4122: A Universally Unique IDentifier (UUID) URN Namespace[4] 類型（變體）， 即上面表格的第二行，其第三高位 為 x，表示該值并無意義，所以該版本只需要10 即可。

10開頭的 hexDigit 十六進制數字字符，其只有四個值。

0b1000   => 8
0b1001   => 9
0b1010   => a
0b1011   => b

用簡單的圖示表示，就是 下面y的部分只會是這 四個值 8, 9, a, b其中的某個值。xxxxxxxx-xxxx-xxxx-yxxx-xxxxxxxxxxxx

簡單測一測,

圖片

所以呢，一個RFC4122[5]版本的 UUID正宗不正宗，這么驗證也是一種手段。

版本（子類型）

上面提到了UUID的類型（變體）， 而這里版本，可以理解為某個類型（變體）下的不同子類型。當然本文討論的是 變體 10 即RFC4122[6] 下的版本（子類型）。UUID的類型（變體）有字段標記，當然 這里的版本也有。

即版本號time_hi_and_version 的第12至15位

圖片

V4版本如下：

圖片

一共有5個版本：

圖片

用簡單的圖示表示，就是 下面V的部分只會是這 五個值 1, 2, 3, 4, 5其中的某個值。xxxxxxxx-xxxx-V xxx-yxxx-xxxxxxxxxxxx

借用uuid 庫演示一下：

圖片

時間戳

先回顧一下兩張圖

圖片

image.png

圖片

第一張是UUID 各部分的組成，time_low ，time_mid， time_hi_and_version 包含了時間戳的不同部分。

第二張是UUID的五個版本，但是只有 V1 和 V2 提到了時間戳，也確實是這樣，除了V1和V2版本真正用了時間戳，其余版本通過不同手段生成了數據填充了time_low ，time_mid， time_hi_and_version 這三個部分。

那這個時間戳 是 開發者們 常用的 Date.now() 這個時間戳嘛, 答案當然不是。

這里的時間戳是一個60位長度的數值。對于UUID版本1和2，它通過協調世界時（UTC）表示，即從1582年10月15日0點0分0秒開始算起的100納秒間隔計數。

比如 2024年1月1日0時0分0秒，這個值時間戳怎么算呢

const startOfUuidEpoch = new Date('1582-10-15T00:00:00.000Z');
const uuidTimestampFromDate = (date) => {
  // 直接計算給定日期距離UUID紀元開始的毫秒數
  const msSinceUuidEpoch = date.getTime() - startOfUuidEpoch.getTime();

  // 將毫秒轉換為100納秒的整數倍，  1 毫秒=1000000 納秒
  const uuidTimestampIn100Ns = Math.floor(msSinceUuidEpoch * 10000); // 每毫秒乘以10,000得到100納秒

  return uuidTimestampIn100Ns;
};

// 計算2024年1月1日對應的UUID V1版本時間戳
const targetDate = new Date('2024-01-01T00:00:00.000Z');
const uuidV1Timestamp = uuidTimestampFromDate(targetDate); 
// 139233600000000000

要保存為60位， 并劃分高位(12)，中間(16)，低位三部分(32)

uuidV1Timestamp.toString(2).padStart(60,'0')
// 000111101110101010000011100010110100110011001000000000000000


time-high     time-mid          time-low
000111101110 1010100000111000 10110100110011001000000000000000

在不具備UTC功能但擁有本地時間的系統中，只要在整個系統內保持一致，也可以使用本地時間替代UTC。然而，這種方法并不推薦，因為僅需要一個時區偏移量即可從本地時間生成UTC時間。

對于UUID版本3或5，時間戳是一個根據4.3 Algorithm for Creating a Name-Based UUID[7]，由名稱構建的60位值， V3和V5 區別是在算法上。

而對于UUID版本4，時間戳則是一個隨機或偽隨機生成的60位值，具體細節參見第4.4 Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers[8]

小結一下，

• 時間戳是即從1582年10月15日0點0分0秒開始算起的100納秒間隔計數，是一個60位值，被分為 高位，中間，低位三部分填充到UUID中。
• 只有V1和V2 真正意義上用了時間戳
• V3和V5 由名字構建而成的60位值
• V4隨機或偽隨機生成的60位值

時鐘序列

時鐘序列（clock sequence）用于幫助避免因系統時間被設置回溯或節點ID發生變化時可能出現的重復標識符。

舉個實例，手動把系統的時間設置為一個過去的時間，那么就可能導致生成重復的UUID.

協議考慮到了這點，就增加了時鐘序列，增加一個變數，讓結果不一樣，當然如果序列也是不變的，那么還是可能重復，所以這個時鐘序列也是會變化的。

如果系統時鐘被設置為向前的時間點之前，或者可能已經回溯（例如，在系統關機期間），并且UUID生成器無法確定在此期間沒有生成時間戳更大的UUID，則需要更改時鐘序列。若已知先前時鐘序列的值，可以直接遞增；否則應將其設置為一個隨機或高質量的偽隨機值。

同樣，當節點ID發生變化（比如因為網絡適配器在不同機器間移動），將時鐘序列設置為隨機數可以最大限度地降低由于各機器之間微小時間設置差異導致重復UUID的可能性。盡管理論上知道與變更后的節點ID關聯的時鐘序列值后可以直接遞增，但這種情況在實際操作中往往難以實現。

時鐘序列必須在其生命周期內首次初始化為隨機數，以減少跨系統間的關聯性。這提供了最大程度的保護，防止可能會快速在系統間遷移或切換的節點標識符產生問題。初始值不應與節點標識符相關聯。

同樣的，這個時間序列只在 V1和V2 是真的按照上面的規則或者約定來執行的。

對于UUID版本3或5，時鐘序列是一個由第4.3 Algorithm for Creating a Name-Based UUID[9]節描述的名稱構建的14位值。

而對于UUID版本4，時鐘序列則是一個如第4.4 Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers[10]節所述隨機或偽隨機生成的14位值。

節點標志符

空間唯一節點標識符，用來確保即便在同一時間生成的UUID也能在特定網絡或物理位置上保持唯一性。

對于UUID V1，這個節點標識符通常基于網絡適配器的MAC地址或者在沒有硬件MAC地址可用時由系統自動生成一個偽隨機數。它的目的是反映生成UUID的設備在網絡或物理空間中的唯一性，即使在相同的時序和時鐘序列條件下，不同的設備也會因為其獨特的節點標識符而產生不同的UUID。

在UUID V2中，雖然不常用，但節點標識符的概念同樣適用，用于標識系統的唯一性，只不過這里的“空間”更多地指向組織結構或其他邏輯意義上的空間劃分。

總之，空間唯一節點標識符是為了保證在分布式系統環境下，即使時間戳相同的情況下也能生成唯一的UUID，以區分不同物理節點上的事件或資源。

對于UUID版本3或5：  節點字段（48位）是根據第4.3節描述的方法，從一個名稱構造而來。對于UUID版本4： 節點字段（同樣是48位）是一個隨機或偽隨機生成的值。

小結

從V1和V2版本來看， UUID最后是想通過 時間和空間 上兩層手段保證其唯一性：

• 時間：時間戳 + 時鐘時序
• 空間：節點標志符（比如MAC地址）

同時考慮了 類型（變體） 和 版本（子類型），即下面這些組信息組成了UUID

• 時間戳
• 時鐘序列
• 節點標志符
• 保留位：即類型（變體）信息
• 版本：V1到V5

因為保留位和版本信息本身是固定的，是可以從最后的32位16進制字符是可以直接或者間接看到的。

再回顧這張圖，是不是比較清晰了

圖片

UUID 的 生成

協議中有具體描述V1, V3和V5, 以及V4的基本流程或者約束。

v4

瀏覽器和nodejs內置的了V4的生成函數， 而且其生成規則相對簡單。對應著協議  4.4.  Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers[11]。

版本4的UUID旨在通過真正的隨機數或偽隨機數生成UUID。其生成算法相對簡單，主要依賴于隨機性：

生成算法步驟如下：

1. 在UUID結構中的clock_seq_hi_and_reserved部分，將最高兩位有效位（即第6位和第7位）分別設置為0和1。
2. 在UUID結構中的time_hi_and_version字段，將最高四位有效位（即第12位至第15位）設置為來自第 4.1.3節[12] 的4位版本號，對于版本4 UUID，這個版本號是固定的0100。
3. 將除了以上已設定的位之外的所有其他位設置為隨機（或偽隨機）選取的值。

不好理解，就看這張圖：

圖片

關于隨機性安全要求， 引用了BCP 106[13]標準文檔，即 RFC 4086[14]。RFC 4086是一份由IETF制定的最佳當前實踐（Best Current Practice, BCP）文檔，其標題為“Security Requirements for Randomness”，該文檔詳細闡述了在實現安全協議與系統時所需的隨機數生成器的要求和特性，確保生成的隨機數具有足夠的不可預測性和熵，能滿足各類安全應用，包括但不限于密碼學應用中的隨機性需求。

總之，生成版本4 UUID的過程中，首先對特定字段的幾位進行固定設置以標明版本和時鐘序列特征，然后其余所有位均通過隨機或偽隨機過程填充數值，以此確保生成的UUID具備全球唯一性和較強的隨機性。

至于v2怎么生成，協議貌似沒有提到， v1 ， v3 和 v5均有提到，這邊就直接翻譯過來，有興趣的可以看看大致邏輯。不敢興趣的直接跳到后續章節

V1

對應這協議 4.2.2.  Generation Details[15] ,按照以下步驟生成的：

1. 確定時間戳和時鐘序列：遵循第 4.2.1 節描述的方法，獲取基于 UTC 的時間戳以及用于 UUID 的時鐘序列。
2. 處理時間戳和時鐘序列：將時間戳視為一個 60 位無符號整數，時鐘序列視為一個 14 位無符號整數，并按順序編號每個字段中的位，最低有效位從0開始計數。
3. 設置時間低位字段（time_low field）：將其設置為時間戳的最低有效 32 位（位 0 到 31），保持相同的位權重順序。
4. 設置時間中間字段（time_mid field）：將其設置為時間戳中的位 32 到 47，同樣保持位權重順序一致。
5. 設置時間高位及版本字段（time_hi_and_version field）的低 12 位（位 0 到 11）：將其設置為時間戳的位 48 到 59，保持位權重順序一致。
6. 設置時間高位及版本字段的高 4 位：將這 4 位（位 12 到 15）設置為對應于所創建 UUID 版本的 4 位版本號。
7. 設置時鐘序列低位字段（clock_seq_low field）：將其設置為時鐘序列的最低有效 8 位（位 0 到 7），同樣保持位權重順序一致。
8. 設置時鐘序列高位及保留字段的低 6 位（clock_seq_hi_and_reserved field 的位 0 到 5）：將其設置為時鐘序列的最高有效 6 位（位 8 到 13），保持相同位權重順序。
9. 設置時鐘序列高位及保留字段的高 2 位：將這 2 位（位 6 和 7）分別設置為 0 和 1，以滿足版本 1 UUID 的標準格式要求。
10. 設置節點字段（node field）：將其設置為 48 位的 IEEE MAC 地址，地址中的每一位都保持原有的位權重順序

V3 和 V5

對應協議的 4.3.  Algorithm for Creating a Name-Based UUID[16]

版本3或5的UUID設計用于從特定 命名空間(name space) 內的且在該命名空間內唯一的 名字(names) 生成UUID。這里的名字(names)和命名空間(name space)的概念應該廣泛理解，不僅限于文本名稱。例如，一些命名空間包括域名系統（DNS）、統一資源定位符（URLs）、ISO對象標識符（OIDs）、X.500區別名（DNs）以及編程語言中的保留字等。在這些命名空間內分配名稱和確保其唯一性的具體機制或規則不在本規范的討論范圍內。

對于這類UUID的要求如下：

1. 在同一命名空間內，使用相同名稱在不同時間生成的UUID必須完全相同。
2. 在同一命名空間內，使用兩個不同名稱生成的UUID應當是不同的（概率極高）。
3. 在兩個不同命名空間內，使用相同名稱生成的UUID也應當是不同的（概率極高）。
4. 如果兩個由名稱生成的UUID相同，則它們幾乎肯定是由同一命名空間內的相同名稱生成的。

生成基于名稱和命名空間的UUID的具體算法步驟如下：

1. 為給定命名空間內所有由名稱生成的UUID分配一個作為“命名空間ID”的UUID；參見附錄C[17]中預定義的一些值。
2. 選擇MD5 [4[18]] 或SHA-1 [8[19]] 其中的一種哈希算法；如果不考慮向后兼容性，建議優先使用SHA-1。
3. 將名稱轉換為其命名空間規定的標準化字節序列形式，并將命名空間ID以網絡字節序排列。
4. 計算命名空間ID與名稱連接后的哈希值。
5. 將哈希值的前四個八位組（octets 0-3）賦給時間低位字段（time_low field）的前四個八位組。
6. 將哈希值的第五和第六個八位組賦給時間中間字段（time_mid field）的前兩個八位組。
7. 將哈希值的第七和第八個八位組賦給時間高位及版本字段（time_hi_and_version field）的前兩個八位組。
8. 將時間高位及版本字段的四位最顯著位（bit 12 至 15）設置為第4.1.3節中指定的相應4位版本號。
9. 將哈希值的第八個八位組賦給時鐘序列高位及保留字段（clock_seq_hi_and_reserved field）。
10. 將時鐘序列高位及保留字段的兩位最顯著位（bit 6 和 7）分別設置為0和1。
11. 將哈希值的第九個八位組賦給時鐘序列低位字段（clock_seq_low field）。
12. 將哈希值的第十至第十五個八位組賦給節點字段（node field）的前六個八位組。
13. 最后，將生成的UUID轉換成本地字節序

獲取 UUID V4

這里就只介紹V4版本，因為V4是基于 隨機或者偽隨機來實現的，只要保證 保留位 和 版本號 的固定，其他的隨機生成就好。

正則 + Math.random

利用Math.random() 方法生成隨機數。

function uuidv4() {
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
    var r = (Math.random() * 16 | 0), v = c == 'x' ? r : (r & 0b0011 | 0b1000);
    return v.toString(16);
  });
}

先固定好格式，執行replace，整體代碼不難，唯一需要提一下的是 (r & 0b0011 | 0b1000) 操作，這里的作用就是設置保留位的值10

r & 0b0011               // 高位，即2,3位 變為 00
r & 0b0011 | 0b1000      // 高位，即2,3位 變為 10

舉個例子, 用9為例，其二進制 0b1001 &

0b1001 & 0b0011   => 0b0011
0b0011 | 0b1000   => 0b1011

crypto.randomUUID

現代瀏覽器也內置 Crypto: randomUUID() method[20]  ， nodejs 15.6.0 版本以上就內置了crypto.randomUUID([options])[21]

crypto.randomUUID()
// 4d93f326-3f48-4a43-929d-b6489f4754b5

URL.createObjectURL

function uuid() { 
    const url = URL.createObjectURL(new Blob([])); 
    // const uuid = url.split("/").pop(); 
    const uid = url.substring(url.lastIndexOf('/')+ 1); 
    URL.revokeObjectURL(url); 
    return uid; 
}
 uuid()
// blob:http://localhost:3000/ff46f828-1570-4cc9-87af-3d600db71304

上面方式產生的都是 v4版本，如果v4版本滿足需求，就沒有必要去引入第三方庫了。

你是否真的需要UUID

在前端，有序后需要給數據添加一個id作為組件的key，這時候理大多數情況是不需要UUID, 也許下面的函數就滿足了你的需求。

let id = 0;
function getId () {
    return id++;
}

后起之秀 NanoID

npm網站， NanoID是這么自我介紹的：

Nano ID 是一個精巧高效的 JavaScript 庫，用于生成短小、唯一且適合放在 URL 中的標識符字符串。這個工具提供了幾個關鍵特性：

1. 體積小巧：Nano ID 的最小化和壓縮版本非常緊湊，大小僅為 116 字節。
2. 安全性：該庫使用硬件隨機數生成器來確保生成的 ID 具有高安全性，可以在集群環境中安全使用。
3. 短小 ID：相較于 UUID（通常包含 A-Z、a-z、0-9 以及 - 符號，共 36 個字符），Nano ID 使用了更大的字符集（包括 A-Za-z0-9_-），從而將 ID 的長度從 36 個符號減少到了 21 個，更便于在有限空間中使用。
4. 可移植性：Nano ID 已被移植到超過 20 種編程語言中，具有良好的跨平臺適用性。

從最新的一周的下載量來對比，首先都是絕對的熱門庫，其次NanoID勢頭很盛。

截圖_20241305051331.png

借用 阿通 給的對比文案：

Nano ID 和 UUID（Universally Unique Identifier）都是用于生成唯一標識符的機制，但它們之間存在一些關鍵差異：

1. 長度與格式：

UUID：標準UUID由32個十六進制數字組成，分為5組，每組之間用短橫線-分隔，例如 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx，總長度為36個字符（包括連字符）。

Nano ID：Nano ID 可配置長度，但默認生成的是較短的字符串，通常包含21個字符，并且可以自定義字符集（默認為 A-Za-z0-9_-）。

2. 唯一性保證：

• UUID：基于時間戳、MAC地址（對于v1 UUID）、隨機數（對于v4 UUID）等多種因素生成，理論上全球范圍內幾乎不可能重復。

• Nano ID：雖然也致力于生成唯一的ID，但由于其較短的長度，在沒有額外存儲或算法保證的情況下，唯一性風險相對較大。不過，通過增大字符集和適當增加ID長度，Nano ID也能實現很高的唯一性概率。

3. 應用場景：

• UUID：廣泛應用于數據庫鍵、資源標識符、網絡協議等需要全局唯一性的場景，尤其在網絡間不同系統間的交互中常見。

• Nano ID：更適合于對ID長度要求嚴格的場合，如URL友好、前端顯示或者存儲空間有限的情況。

4. 性能與存儲成本：

• UUID：由于較長的字符串長度，存儲和傳輸時可能會占用更多空間。

• Nano ID：因其短小，Nano ID在存儲和帶寬消耗上更有優勢。

5. 安全性：

• UUID v4 是基于強隨機性生成的，因此安全性較高，不易被預測。

• Nano ID 也可以使用安全的隨機源生成，同樣能夠達到較高的安全性，但在默認設置下，考慮到生成長度和字符集的選擇，如果不在生成邏輯上做特殊處理以增加熵，其安全性可能不及UUID。

綜上所述，選擇Nano ID還是UUID取決于具體的應用需求，如果重視存儲效率和簡潔性，同時能接受合理的唯一性保證策略，則Nano ID可能更為合適；而在需要絕對唯一性和不考慮存儲效率的場景下，UUID往往是更好的選擇。

引用

RFC4122: A Universally Unique IDentifier (UUID) URN Namespace[22]UUID那些事[23]

參考資料

[1]RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace: https://www.rfc-editor.org/rfc/rfc4122

[2]4.1.2.  Layout and Byte Order: https://www.rfc-editor.org/rfc/rfc4122#section-4.1.2

[3]4.1.1.  Variant: https://www.rfc-editor.org/rfc/rfc4122#section-4.1.1

[4]RFC4122: A Universally Unique IDentifier (UUID) URN Namespace: https://www.rfc-editor.org/rfc/rfc4122

[5]RFC4122: https://www.rfc-editor.org/rfc/rfc4122

[6]RFC4122: https://www.rfc-editor.org/rfc/rfc4122

[7]4.3 Algorithm for Creating a Name-Based UUID: https://www.rfc-editor.org/rfc/rfc4122#section-4.3

[8]4.4 Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers: https://www.rfc-editor.org/rfc/rfc4122#section-4.4

[9]4.3 Algorithm for Creating a Name-Based UUID: https://www.rfc-editor.org/rfc/rfc4122#section-4.3

[10]4.4 Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers: https://www.rfc-editor.org/rfc/rfc4122#section-4.4

[11]4.4.  Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers: https://www.rfc-editor.org/rfc/rfc4122#section-4.4

[12]4.1.3節: https://www.rfc-editor.org/rfc/rfc4122#section-4.1.3

[13]BCP 106: https://www.rfc-editor.org/info/bcp106

[14]RFC 4086: https://www.rfc-editor.org/rfc/rfc4086

[15]4.2.2.  Generation Details: https://www.rfc-editor.org/rfc/rfc4122#section-4.2.2

[16]4.3.  Algorithm for Creating a Name-Based UUID: https://www.rfc-editor.org/rfc/rfc4122#section-4.3

[17]附錄C: https://www.rfc-editor.org/rfc/rfc4122#appendix-C

[18][4: https://www.rfc-editor.org/rfc/rfc4122#ref-4

[19][8: https://www.rfc-editor.org/rfc/rfc4122#ref-8

[20]Crypto: randomUUID() method: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID

[21]crypto.randomUUID([options]): https://nodejs.org/docs/latest/api/crypto.html#cryptorandomuuidoptions

[22]RFC4122: A Universally Unique IDentifier (UUID) URN Namespace: https://www.rfc-editor.org/rfc/rfc4122

[23]UUID那些事: https://www.cnblogs.com/yjf512/p/9045341.html