換掉UUID，NanoID更快更安全！
往期熱門文章：
1、新來(lái)的后端整的接口文檔看著真不優(yōu)雅！ 2、如何優(yōu)雅的寫 Controller 層代碼？ 3、SpringBoot+Nacos+Kafka簡(jiǎn)單實(shí)現(xiàn)微服務(wù)流編排 4、幾行代碼，搞定 SpringBoot 接口惡意刷新和暴力請(qǐng)求！ 5、程序員坐牢了，會(huì)被安排寫代碼嗎？
文章來(lái)源：https://c1n.cn/WcAl0
前言
了解 NanoID 及其用法
局限性和未來(lái)重點(diǎn)
在將來(lái)……
前言
UUID 是軟件開(kāi)發(fā)中最常用的通用標(biāo)識(shí)符之一。然而，在過(guò)去的幾年里，其他的競(jìng)品挑戰(zhàn)了它的存在。
其中，NanoID 是 UUID 的主要競(jìng)爭(zhēng)對(duì)手之一。
因此，在本文中，我們將展開(kāi)討論 NanoID 的功能、它的亮點(diǎn)以及它的局限性，以便讓我們更好地了解何時(shí)使用它。
了解 NanoID 及其用法
對(duì)于 JavaScript，生成 UUID 或 NanoID 都非常簡(jiǎn)單。它們都有對(duì)應(yīng)的 NPM 包來(lái)幫助我們實(shí)現(xiàn)生成。
import { nanoid } from 'nanoid';
model.id = nanoid();
你是否知道 NanoID 每周的 NPM 下載量超過(guò) 1175.4 萬(wàn)，并且運(yùn)行起來(lái)比 UUID 快 60%？
此外，NanoID 比 UUID 年輕了將近 7 年，而且它的 GitHub 星數(shù)已經(jīng)比 UUID 多。
https://www.npmtrends.com/nanoid-vs-uuid
我希望這些數(shù)字已經(jīng)說(shuō)服你去嘗試 NanoID。但是，這兩者之間的主要區(qū)別很簡(jiǎn)單。它歸結(jié)為鍵使用的字母表。
由于 NanoID 使用比 UUID 更大的字母表，因此較短的 ID 可以用于與較長(zhǎng)的 UUID 相同的目的。
| NanoID 只有 108 個(gè)字節(jié)那么大
與 UUID 不同，NanoID 的大小要小 4.5 倍，并且沒(méi)有任何依賴關(guān)系。此外，大小限制已用于將大小從另外 35% 減小。
大小減少直接影響數(shù)據(jù)的大小。例如，使用 NanoID 的對(duì)象小而緊湊，能夠用于數(shù)據(jù)傳輸和存儲(chǔ)。隨著應(yīng)用程序的增長(zhǎng)，這些數(shù)字變得明顯起來(lái)。
| 更安全
在大多數(shù)隨機(jī)生成器中，它們使用不安全的 Math.random()。但是，NanoID 使用 crypto module 和 Web Crypto API，意味著 NanoID 更安全。
此外，NanoID 在 ID 生成器的實(shí)現(xiàn)過(guò)程中使用了自己的算法，稱為統(tǒng)一算法，而不是使用“隨機(jī) % 字母表” random % alphabet。
我們創(chuàng)建了一個(gè)高質(zhì)量的技術(shù)交流群，與優(yōu)秀的人在一起，自己也會(huì)優(yōu)秀起來(lái)，趕緊點(diǎn)擊加群，享受一起成長(zhǎng)的快樂(lè)。
| 它既快速又緊湊
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz-
此外，NanoID 支持 14 種不同的編程語(yǔ)言，它們分別是：C#、C++、Clojure 和 ClojureScript、Crystal、Dart & Flutter、Deno、Go、Elixir、Haskell、Janet、Java、Nim、Perl、PHP、帶字典的 Python、Ruby、Rust、Swift。
| 兼容性
它還支持 PouchDB、CouchDB WebWorkers、Rollup 以及 React 和 Reach-Native 等庫(kù)。
import { nanoid } from ‘@reduxjs/toolkit’
console.log(nanoid()) //‘dgPXxUz_6fWIQBD8XmiSy’
| 自定義字母
如下所示：
import { customAlphabet } from 'nanoid';
const nanoid = customAlphabet('ABCDEF1234567890', 12);
model.id = nanoid();
在上面的示例中，我將自定義字母表定義為 ABCDEF1234567890，并將 Id 的大小定義為 12。
| 沒(méi)有第三方依賴
由于 NanoID 不依賴任何第三方依賴，隨著時(shí)間的推移，它能夠變得更加穩(wěn)定自治。
從長(zhǎng)遠(yuǎn)來(lái)看，這有利于優(yōu)化包的大小，并使其不太容易出現(xiàn)依賴項(xiàng)帶來(lái)的問(wèn)題。
局限性和未來(lái)重點(diǎn)
根據(jù) StackOverflow 中的許多專家意見(jiàn)，使用 NanoID 沒(méi)有明顯的缺點(diǎn)或限制。
非人類可讀是許多開(kāi)發(fā)人員在 NanoID 中看到的主要缺點(diǎn)，因?yàn)樗拐{(diào)試變得更加困難。但是，與 UUID 相比，NanoID 更短且可讀。
另外，如果你使用 NanoID 作為表的主鍵，如果你使用相同的列作為聚集索引也會(huì)出現(xiàn)問(wèn)題。這是因?yàn)?NanoID 不是連續(xù)的。
在將來(lái)……
NanoID 正逐漸成為 JavaScript 最受歡迎的唯一 id 生成器，大多數(shù)開(kāi)發(fā)人員更喜歡選擇它而不是更喜歡 UUID。
https://www.npmjs.com/package/nanoid
上述基準(zhǔn)測(cè)試顯示了 NanoID 與其他主要 id 生成器相比的性能：使用默認(rèn)字母表每秒可生成超過(guò) 220 萬(wàn)個(gè)唯一 ID，使用自定義字母表每秒可生成超過(guò) 180 萬(wàn)個(gè)唯一 ID。
根據(jù)我使用 UUID 和 NanoID 的經(jīng)驗(yàn)，考慮到它的小尺寸、URL 友好性、安全性和速度，我建議在任何未來(lái)的項(xiàng)目中使用 NanoID 而不是 UUID。
因此，我邀請(qǐng)您在下一個(gè)項(xiàng)目中試用 NanoID，并在評(píng)論部分與其他人分享您的想法。
往期熱門文章：
1、MySQL 暴跌！ 2、超越 Xshell！號(hào)稱下一代 Terminal 終端神器，用完愛(ài)不釋手！ 3、IDEA 官宣全新默認(rèn) UI，太震撼了！！ 4、讓你直呼「臥槽」的 GitHub 項(xiàng)目！ 5、Kafka又笨又重，為啥不選Redis？ 6、50多個(gè)高頻免費(fèi) API 接口分享 7、IDEA公司再發(fā)新神器！超越 VS Code 騷操作! 8、我懷疑這是 IDEA 的 BUG，但是我翻遍全網(wǎng)沒(méi)找到證據(jù)！ 9、Spring MVC 中的 Controller 是線程安全的嗎？ 10、Gitee 倒下了？？？